Ironically to your point, I think adding a ConcurrentHashMap because it might be multithreaded eventually IS premature optimisation.
The work can be done in future to migrate to using ConcurrentHashMap when the feature to add multithreading support is added. There's no sense to add groundwork for unplanned, unimplemented features - that is premature optimisation in a nutshell.
Typing ten extra characters is an investment that pays off vs the overhead of doing any piece of work in the future. There's no real downside here, it doesn't make the code more complex, it gives less surprising results.
I think you are conflating YAGNI and premature optimisation and neither apply in this case.
The point of the premature saying is to avoid additional effort in the name of unnecessary optimization, not to avoid optimization itself. Using a thing that's already right there because it might be better in some cases and is no more effort than the alternatives is not a problem.
I would agree if I were adding a dependency to Gradle or something. In this case it’s just something that conforms to the same interface as the other Map and is built into every Java for the last 20+ years. The max amount of effort I am wasting here is the ten extra characters I used to type “Concurrent”.
My point was that even if it is not optimal, there’s really no utility in bickering about it because it doesn’t really change anything. The savings from changing it to regular hashmap will, generously, be on the order of nanoseconds in most cases, and so people getting their panties in a bunch over it seems like a waste of time.