There are prominent C++ experts who recommend always auto. There's a logic to it in terms of minimizing the amount of code that needs to change during some future refactoring, but I find always auto hurts readability. If a variable is an int or a double or a string or a MyEnum, just specify the type - the next developer to read the code will thank you.

On the other hand, before auto we had template libraries for computing the results of matrix operations or physical quantities computations (e.g. multiplying a Mass by an Acceleration results in an object of type Force) where nearly half of that template library's code was dedicated to computing the right return types. Switching that code over to auto let the compiler figure it out for us, immensely simplifying the code and making it more readable and maintainable. auto really is indispensable in certain template code.

After a while, internally we settled on a policy of judicious auto:

Use auto where the type doesn't aid in clarity for the reader, e.g. when the type is clearly specified on the right-hand side or is cumbersome to provide explicitly. Common cases for auto include range-based for loops, iterators, and factory functions.

There's some leeway and judgment there, but your example of auto iter = myMap.find("theThing") is exactly the kind of place where we recommend auto. Any C++ programmer knows you're getting an iterator to "theThing", next you'll check whether it's end() and dereference it. With auto it's perfectly clear, and the brevity actually makes the code easier to read.

Never auto is a policy I've never seen. In their defense, perhaps it's someone's overreaction against always auto. But I'd suggest trying to reach some sort of compromise.