I understand your argument about force, and although I very much sympathize with the general tendency to seek to do things without what one could in a sense call "force", I think there are a few factors which are obscuring matters here.
For one, I think we have to be careful that we are not engaging in a fallacy of equivocation. While it is especially disconcerting to see "force" being used ot justify even well-intended behaviors, when understood as compulsion under threat of violence or imprisonment by the state, obviously we are not talking about anything remotely similar in degree here (assuming all would even agree that this is indeed a form of compulsion at all).
So saying "it's always wrong to force things on people" might be seen as gaining credence by attacking the strawman of a supposed claim justifying physical compulsion. This brings me to my second point which is about the polemical-sounding nature of engagement with such a fallacy.
Polemicists use ambiguous language such as this to obscure matters in the course of seeking to win temporary support for their arguments, but their doing so also obscures a detached search for truth to really look dispassionately together at what is at hand without complicating things with language that may be interpreted in a way that evokes more moral outrage than is relevant.
In this vein, to highlight the polemical impression such an argument gives from the other side, suppose I were to have used similarly equivocal language to suggest that you were in fact "forcing" others. I am not supporting this kind of polemical language, because I don't find such strong terms helpful, but it may incidentally also highlight the point about polemicism as well as the logical points about ESM breakage that I wish to make.
A polemicist might claim that you were actually the one being forceful on insisting on your viewpoint or that you were seeking to "force" the project to maintain backward compatibility. Again, this would be unfair, given the strong connotations of physical pressure of "force", but I expect you can admit, you are indeed seeking to exert some "force" in a weaker sense. True, you are not holding a gun to our head, but neither are developers of ESM-only projects. ESM-only projects are simply not doing work that you want them to continue doing.
While you might respond that there is some kind of social contract calling on us to help others, so this "burden" on us was merited, even setting aside your categorical rejection of "force" in pressuring us, still, why are we not part of the social contract too? Why are the needs of the many of us who don't want to be stuck with extra procedures not relevant? Is our free labor here a kind of slavery (yes, more potentially polemical language) whereby we are compelled to do your bidding rather than our own? This is not to mention some of us not wanting to prolong the community having no incentive to get around to supporting ESM--what about that social contract (to "think of the children" if I may further the polemicism)? If there were a technology that could speed up the Internet by 100 times, and yet it required 1 hour of pre-announced internet down-time, "forcing" users of the internet to suffer for the benefits of a new innovation, would you not be at least open to considering the idea? What if it were 1000 times the speed and only five minutes of down-time. Surely, you can see there is a spectrum here.
But my main goal is to set the polemical discussions of "force" aside, and instead get back to suggest in non-charged language that one might argue that you are putting the burden you wish to seek to avoid instead on ESM-only-favoring developers and future generations due to some absolute, unyielding value being assigned to backward compatibility.
Now backward compatibility is an understandably admirable standard to strive for, especially in fields like the web where there is such a vast prior output (and by many not so technical users) that one would not wish to lose access to it).
But another factor I would like to argue, unrelated to polemics, is that this form of "backward compatibility" is akin to the type of breakage we see as in "breaking the web". This can hardly be compared in degree to purposely creating a browser which no longer is capable of displaying old websites. We're talking about competent developers having the inconvenience of needing to tweak their code (and who regularly need to make tweaks anyways, e.g., to avoid vulnerabilities or support their userbase), and yes, perhaps face some suffering as the dependency chain is fixed or alternatives are found. But the changes required are not extreme in degree, even if it is admittedly of no small consequence either. The impossibility of contacting all website owners to "fix" their code is not the same as contacting all non-ESM projects to retool their support for ESM. In addition, most ESM projects today can continue using non-ESM code, so the burden is really only on non-ESM or polyglot dependees rather than dependents. As developers start getting used to creating ESM code, they will make ESM-friendly or polyglot versions--because they wish to support the community, and the problem can be assisted from the ground up.
I'm not sure why demos matter; that's not the important audience for software. We should be optimizing for actual production usage, not one-off weekend projects.