This has not been my experience at all. I have watched many developers progress from being coders ("hammers") to being thoughtful architects who have no trouble seeing the forest through the trees and re-imagining problems from first principles.
Of course people will try to lean on the skills they already have when tasked with solving a problem. This is completely orthogonal to whether they have any trouble adding to their skills. The former is often the correct response to solving an immediate problem as quickly as possible, while the later is something that happens over a longer period of time and many projects.
Your assertion that people get stuck in this "hammer" mindset and have a harder time learning once there does not match my observations at all. From my experience the people who see a brick wall between these two skills fall into two categories. I don't know if you fall into either of these, but it would not surprise me.
1. People on the "architect" side of the wall who want to justify their feeling of superiority, their higher salaries, or their enterprise's highly regimented hierarchy that separates the two.
2. People on the "hammer" side of the wall who suffer from imposter syndrome and seeking to justify their sense of inadequacy.
Both are incorrect. There is no wall. In fact, between those two skills is a well worn and wide road that most developers move along throughout their career. Many don't complete the journey to your (or my) ideal of "software enlightenment", but most make progress, and being trained as a "hammer" doesn't stall the progress, it helps.
Also worth reflecting that software is still relatively new and we really don't know what we're doing. We're all making it up as we go along for the most part, so let's not be so quick to prejudge the capabilities of our peers. All of our enlightened architecture may seem pretty foolish a century from now, or even a year from now.