Your question is the crux for this whole discussion. What most businesses get wrong is that not everyone is your customer. That means you have to learn to say to a customer: “sorry this product is not for you, perhaps you should try …”.
Firstly, recognize that all popular frameworks do work, meaning that they do they the job that they are intended to do. React and Angular were developed to solve the problems that Facebook and Google have. Not every company has these type of problems nor needs such heavy weight solutions. Proper architecture, componentization and disciplined code structure is more important than the technology that you choose. Too many developers focus on the shiny or are protecting their own choices.
Secondly, the “market” is saturated with frameworks, widgets and add-ons. Trying to roll your own framework / application is fraught with challenges: Open Source Challenges. The “marketing noise” is deafening sometimes. This makes it very hard to pick a way forward. And then comes the maintenance problem after your application is in production! This is something developers ignore because it’s more fun to do new things. Business managers, however, need to pay for customer support, after that fact and it’s boring and not fun.
Thirdly, beware of the “hammer” problem; meaning that if you only own a hammer then everything looks like a nail. In software, as in life, we know that one size does not fit all. Evolutionary forces always drives specialization. If you just need a marketing site, there are a number of solutions such as Next. Unfortunately, their market will be chewed up by “paint by numbers” type of website creators like Wordpress, Wix, etc. Every product needs to be positioned properly to meet the needs of the end customer. Focusing on silly things like GitHub stars, marginal performance differences, popular technology is not a great sales pitch. Showing how a customer is better off adopting your solution gets more sales. Real business oriented customers don’t care about what technology is under the covers as long as it produces the required business outcome and it gets supported.
If we shift out focus to the business side, we need to consider the real cost not only for development, but also the bigger cost of maintenance. New and shiny is simply not relevant here, but rather consistency, ease of use, good support, stability , etc, etc.
If we look at the state of Meteor today, I submit that Meteor meets the needs of business minded developers. It has had a decade of being in-market, being stress tested and improved to solve real worthwhile problems. The Meteor stack is actually very small, meaning that training a javascript back-end developer is almost trivial. The front-end will always need a developer that understands some other product such as Blaze, Vue, Svelte, React or whatever anyway! Just add a bit of Meteor front end spice to complete the project and that is also easy to learn. Hence the Meteor adoption barrier is really low for javascript folks and should not be an issue.
Meteor may not be the best solution for simple marketing sites, but then neither is any other framework: use Wordpress. On the other hand, if you are building an application (enterprise or SaaS) that has complex business logic, needs some real-time data transfer and client side reactivity, then Meteor shines.
Alternatively, you can cobble together an Express server, add database connectors, build your own websocket connectors, authentication, web pack configuration … and eventually you end with something almost as good as Meteor, but you have to maintain it yourself. But why bother re-inventing the wheel. Just get on with delivering a solution to your customers and get paid for a good outcome.
My two cents.
. It’s clear that you did put a lot of work in it. Though I agree with 
