I wonder how you justify that, because I'm currently maintaining a vue project in production and couldn't disagree more (honest question)
I am sure majority of developers have had two or more projects using the same framework/library and found the difficulty of maintaining them different.
Maintenance of revenue generating code is a unique beast - and rarely has the framework been the magical differentiator.
Vue may be right or wrong, but nobody wishing for special case features can claim to be surprised. If you picked Vue knowing you need a bunch of special case features, that’s on you.
Which is much easier to attain if you're comfortable with only a single person being allowed to write code. Personally, I wouldn't use Vue in any business-oriented application for this exact reason. The "bus factor", or as I would call it, "If and when Evan decides to stop caring about Vue", is enough to make Vue dead in the water as a legitimate FE library choice (to me).
Here you can find the code additions Github Insight.
The org can have 49 people in it, but 48 of them are not writing code for Vue.js.
As long as the maintainers are responsive to bug fixes and key feature requirements (since they aren’t accepting of outside contributors adding them), then this is fine, possibly even optimal in terms of quality.
The trouble comes in if they both don’t allow many outside contributions and at the same time they pull the same unjustified complaint of a lot of OSS and say because they aren’t paid for their time, they will prioritize what interests them rather than what resolves painpoints or missing features users need. You definitely can’t have it both ways.