My belief is that your first goal should be cognitive optimization. I.e. make it simple and clear. That includes using hash maps when that is the proper data structure since that’s is what is called for at a base design level.

The next step is to optimize away from the cognitively optimal, but only when necessary. So yeah it’s really crazy this was ever a problem at all.

OTOH, at some point what is good from a cognitive viewpoint depends on what idioms you use. So it can be helpful to actively chose which idioms you use and make certain to not use those that tend to blow up performance wise.

Given the current code example, I don't even thing idioms come into it. Here a hash map data structure was called for regardless of whatever idioms come into other parts of the design. This is just fundamental and has nothing to do with functional programming, OOP, etc.

This is the key point: premature optimization would be e.g. denormalising a database because you think you might have a performance problem at some point, and breaking the data model for no good reason.

Here the wrong data structure has been used in the first place.

If it doesn't change semantics, it's optimization.

It's just a zero cost one, so if anybody appears complaining that you are caring to choose the correct data structure and that's premature (yeah, it once happened to me too), that person is just stupid. But not calling it an optimization will just add confusion and distrust.

Exactly. And not only being able to pick the correct data structure for the problem, (and possibly the correct implementation), but being able to know what is going to need attention even before a single line of code is written.

Most of my optimization work is still done with pencil, paper and pocket calculator. Well, actually, most of the time you won't even need a calculator.