Yes, that's exactly right. And Go takes a relatively strict stance on making the _how_ obvious to the programmer. It goes out of its way to avoid hiding O(n^k) loops behind language sugar like map or fold, for example.
I'm unclear where algorithmic complexity is coming into this. Can you clarify what you're trying to imply?
Can you given an example where map might increase algorithmic complexity like that where the imperative version would not?
What makes map different is that it separates the looping mechanics (incrementing, initializing and appending to the collection) from the actual computation we want to perform on each element. It's just separation of concerns.
You're right: map separates looping mechanics from computation. In Go, that's a bit too much obscurity.