I’m not quite sure where this 1% figure is coming from, but with 14 million users, that’s still 14,000 users this would banish from Discourse. Just to add some CSS and performance tweaks?
As to “What number of users should be able to hold the remaining percentage from taking advantage of their up to date software?”… why can’t that number be something far, far less than 1%, much closer to 0% than 1%? I’d argue Discourse should be taking the opposite approach, not needlessly making backward-incompatible changes unless there is an overriding critical fix or major feature that absolutely requires it, AND there is widespread user demand for it.
The inverse of that question is “How many users are we willing to cut off to chase some minor conveniences with low to no user-facing impact?” Is a small performance boost that will barely be noticeable on anything but careful benchmarks worth cutting off 14,000 people from their communities?
What sort of “up to date software” are forum users clamoring for…? It’s a forum. People read text and answer text posts. It’s scary that the devs keep saying “we have to keep moving forward” while your actual customers are like, wait, why, none of these features mean anything and you’re cutting real people off.
I feel like this is the exact opposite approach that you’d expect stable, old forum software like Discourse to take. If you want to experiment with new features, that should happen on a unstable canary branch that people have to explicitly opt into, and the main branch should be LTS by default. Not only are you not offering progressive enhancements, you’re also not offering graceful degradations. That is a choice, not some inherent part of software development. You’re choosing to move faster than your users can keep up with.
And your hosted communities have no choice at all. The ones paying you for their community, not to be a tech demo and JS playground.
THIS is why it’s a cultural issue and not a technical one. Thank you for at least being willing to just say it out loud. You’ve weighed the costs of this in dev hours vs estimated user impacts, and in your math, the users are worth less than the cost it would take to make a basic posting version. There’s no other way to say it: You don’t value your real users and communities as much as developer shortcuts 
Sorry to take this quote just a little out of context, but… if you stopped thinking in terms of percentages and thought about the impacts to real individual people in their communities, perhaps the math would look different?
This whole thing is a bit Stalinesque, telling people that they’re basically a disposable statistic because they’re too poor to upgrade hardware or that it’s their own fault for not being willing & able to jump through hoops to install another operating system or compatibility layer or browser fork… just so that they can keep posting text messages on a forum they’ve been a part of for many years?
This is the sort of cost-benefit I’d expect to see from a major new version, like a complete rewrite, not from some minor, invisible developer-facing features that might have some small performance benefits =/ It’s really unfortunate that your company is taking this stance, IMHO, but still… I really do appreciate the transparency.
OK. Anyway, enough whining. I have a potentially/hopefully more constructive question…
If we assume that a basic HTML mode would be helpful for some small # of users, but it’s not something Discourse wants spend to resources on building itself… is this something feasible for the open-source community to potentially take on? It seems a bit too big to be something like a plugin, while still being too small for a whole separate project (like Discorkie).
Would it be conceivable to try to scope this as an alternate open frontend that works with the current APIs, and if so, would there be any chance of getting such a thing (if ever built and tested) to be “officially” accepted/integrated into the main software such that it could also be used on hosted Discourse instances (which is where one of my affected communities is)?
Along those lines, do you have any sort of API versioning/stability system that such an alternative frontend could track?
Maybe the answer there is still a variety of "no"s for various reasons, and if so, that’s fine, but if it’s at all feasible… might be interesting to think about? Not asking for a full-scale feasibility study, maybe just some gut feelings?
I am not certain if such a thing could ever take off or be maintained. Not many devs like working on old software using HTML and minimal JS (but there are still some, like the HTMX folks). Just a thought.