It's completely orthogonal to that. It's not about what language you are using but about how you write the code in that language. The "premature optimization" thing can easily be intepreted as "it's OK to be lazy" and I think that's a misinterpretation.

Just making up an example, often I need to return multiple values from a function in languages that don't directly support that. The pure & efficient way might be to make a new data structure and return that. The "lazy" way is to just stuff them in a map / dictionary / hashtable and return it instead. The cost of those key-value lookups is enormous compared to a direct field lookup, but I can rationalize it as avoiding "premature optimziation". But if you end up with a whole code base that is doing this, eventually the whole thing is operating an order of magnitude slower than it should be. (it's also going to be a nightmare to maintain and refactor, but that's another story ...).

It's not okay to be lazy. But it's wise to prioritize architecture over performance until you have numbers to show you where you should put necessary optimizations. In my experience, optimized code is almost always harder to work with, so there better be a good reason to write it that way.

It's a lot easier to optimize well-architected code than to re-architect optimized code.

If you find yourself regularly having to force that kind of behaviour out of a language that doesn't support it, you're using the wrong language or you have a bad design.