To me, that's programming in a nutshell. Or at least what it should be.
On the other hand, feature poor software is not necessarily simple. Simplicity is hard to achieve. It requires a lot of thought and usually a fair amount of iteration. "Don't touch that code because it doesn't have a good ROI" is also a surprisingly good way to slam the breaks on a project.
Maintaining velocity (or even increasing it) requires a delicate balance of avoiding work that will harm you and encouraging work that will help you. There needs to be a dialog between stakeholders and developers that's 2-way to accomplish this.
Yes this swings both ways. I worked at a startup where every feature improvement was shouted down as a waste of opportunity cost.
They found a decent local maxima but their growth stalled and they degraded into a consultingware company. The more ambitious devs bailed because there was no room for growth.
I'm curious - what were the devs doing with their time, if feature improvements were constantly being vetoed? Were they being kept busy with other tasks which you consider lower-priority, or were they just sitting idle?
Yeah it was a really weird culture, there was definitely some quiet time where I would propose a product improvement but still get no traction. Eg the product website was really embarrassingly 90s, they would let us A/B test customer deployments but not their own site.
There also was a lot of repetitive content scraping tasks that should have been improved and resulted in excessive pager duty (hard to explain but think fragile regexes that parsed customer HTML). That was the last straw for me, I'll do pager duty but not every night just because the PHB is a fool.
They mostly burned our time on trivial consultingware requests instead of improving the core product. I eventually started sneaking core enhancements in by padding out the customer work and just not telling anyone.
This is the same PHB who threatened to fire me because I had to rush my partner to hospital with a concussion. Wonderful human being that.
It's not a strategy I approve, but it can be effective from a commercial stand-point, specially if the half that doesn't work is the half barely used in real life.
It was specially true in the past, with on premise software where clients were in a kind of lock-down with the software provider. Today, as we move more and more towards SaaS, this approach is far more risky because your client could easily switch to another service provider.
More seriously, this kind of situation can happen without ill intent, simply have a fast developer with a strong personality and he will become the lead for everything and the only one able to understand the code base.
Also the velocity of an individual developer can be overvalued and mistaken for a 10x, it's certainly easier and faster to write spaghetti code instead of a well designed/architectured code base, but doing so can have dramatic effects down the line, or even immediately for the other developers in the team. Yet it can be a quality in critical situation (like our startup will shutdown if feature X is not implemented in 2 days).
It can be hard to differentiate between a developer like I describe and a real 10x developer you describe. The applications we designed can be quite difficult to implement depending on the complexity of the domain specific logic the application deals with. Sometimes it's impossible to recognize between complexity caused by the application architecture (generally avoidable) or complexity inherited by the overall domain logic (nearly unavoidable).
And lastly, it's never, ever as black and white as I describe.
That being said, your colleague seems like a really good developer, able to see the big picture and steer a code base in the right direction. I hope for you that he will part of your team for a very long time.