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.
Sure, though I personally am not a fan of labeling people, except perhaps for the persistently and deliberately malicious or deceptive, and even then, solely for protection of others. I think people are more willing to contemplate issues without labels hanging around them in a negative context. I mean it can sometimes be helpful to refer to tendencies as "liberal" or "conservative", for example, but the terms being used in a hostile context do not conduce to people of good will objectively examining a question with justice. We certainly don't need such firmly affixed or harsh labels of people in the open source world either (though labeling behaviors is a different matter).
I think that is a very fair question and generally objective representation, though instead of "harm reduction", I think it would be more objective to a fuller discussion to characterize it as a question of maximizing the benefit/cost ratio since one ought to take into account benefits as well (even if not treating all costs laid on users as equally offset by some marginal benefits). When allowing for raised speed limits, for example, it is simply the case to be likely that fatalities will increase, yet societies support the (non-individually-targeted) distribution of the high cost in favor of the benefits. Society cannot only function based on harm avoidance. Even if one thinks of it in terms of the "harm" of not being able to get to work as expeditiously, it is kind of a negative focus, so I think more illuminating to simply speak to it as being about a balance between both.
There is one other slight benefit to mention, even though largely just another side of the same coin. In all likelihood, ESM-only distributions would lead more quickly to the source code also being moved away from CJS, thus allowing for a uniform standard across environments in source. Beginners have just one syntax to learn, tooling related to querying AST is simplified, etc. I'll admit this is probably even less consequential than reducing build steps per se (since build steps are not quite marginal, as the freedom to quickly experiment and deploy can lead to more projects or proofs-of-concept getting off the ground). But not entirely negligible. (See the next block on minimization.)
The rest is fair, I think, but one doesn't need minifiers for quick demos of and experiments with smaller-size libraries (something I find myself working on and with fairly often).
I think you mean technical benefits given the above-mentioned. But sure, to the rest of your comments, your arguments appear reasonable to my however limited ears.
Though I think "impossible" is a bit too strong as the developer community does tend to submit PRs, make forks, or as needed start from scratch, though I'll concede it is a rather high cost, especially for a pretty negligible benefit. So I think this all gets us much closer to the real crux of the issue.
If a society costs engages in changes which are acute for some individuals and industries and the benefits are thin and widely distributed, such as with free trade, this will be hotly contested as it is.
And here, we are even admittedly talking about widely distributed costs, making for a change that is indeed less likely to be warmly received, especially in the short term.
So indeed it is possible that like VHS and Beta-max, the community will simply reject the drive to the superior outcome due to the cost and things will carry on as usual.
However, developers tend, I think, to be more conscientious, seeking to stay ahead of the curve, preferring the "ideal" solution even if at some cost to themselves. I'll concede that ESM-only is no super strong selling point, but developers also do like a sense of cleanness as well as practicality.
I don't think this is something to be highlighted on a case by case basis, especially if looking merely at the present time. I mean the marginal benefits mentioned do exist in some sense now, but it is likely to suffer from an adoption cost as well, so practically its evident net benefits aren't anything to speak of now.
I think the implementers now are more acting from idealism in wanting to see adoption--much less dramatically so, but not too unlike the developers in the dark ages of IE's stagnation over the open web who resisted its lack of progress by making apps which left out IE support, not so much out of spite perhaps as for convenience in being able to build quick demos, or non-commercial sites that way (even if coming at a cost of reducing uptake) and at times a touch of idealism. But this idealism surely had its impact in leading us to drop off the cruft and lack of standard behavior in needing to target both IE and the rest, toward just being able to target one standard, except when it comes to cutting edge features still under development.
So the benefits I think in this case are simply that such actions can prod changes for the sake of tomorrow, albeit admittedly with pain in the here and now, but which can lead ultimately to however small perpetual ongoing benefits into the future, leading to a single format--a format which is inarguably better in being standard, uniform across environment, and ultimately fostering a minimization in build steps.
I concede that the cost is quite high relative to the benefits, however, and it will probably be resisted by most until the costs of not refactoring become too high and until critical mass makes it easier to use ESM exclusively.
While one could well argue that encouraging dual package support would lessen the pain of transitioning, I think this will be resisted because:
Existing CJS projects often do not like to add to their build complexity or distribution size, especially at a time when their users are not clamoring en masse for ESM distributions. Idealists might change, and the agreeable, but that's all.
Many remain unaware of the benefit I spoke of earlier that one can still use ESM as is in browser demos, or certain other non-Node environments, so even those which use ESM in source may be disinclined to provide an ESM distribution, causing a hassle for ESM users akin to a popular project not providing binaries--you have to figure out how to roll it up/pack it yourself.
As you say, even ESM-only idealists might use CJS dependencies. This is an advantage for easing the pain of transitioning, but that assumes net efforts are in fact being made to transition.
Projects with mixed dual ESM/CJS-supporting dependencies are likely to do little to anything to conduct the prodding necessary to see a transition take place for projects away from CJS in source and/or toward ESM-only distributions to get to the benefits desired, especially if even new projects feel it is simpler to just use CJS to do their own avoidance of a build step if it comes at no cost. As with moral hazard, there is little incentive to change for most. Dual support projects with ESM in source may at least encourage familiarity with ESM, but they don't move the needle away much for projects continuing to use CJS only (and they don't give the benefits of avoiding a build step unless the source is a self-sufficient distribution file itself).
Albeit yes, with exaggeration of the benefits at the outcome, I think ESM-only projects are a bit like no-smoking restaurants at the beginning of such movements. They will annoy customers even at some cost to themselves, but they cause notice of the issue and increase the likelihood of change. Unlike restaurants with no-smoking sections, they provide an entirely smoke-free environment even if non-welcoming to smokers. Yes, smoke is more clearly a harm, but one can plausibly express the lack of a cross-environment standard as a "harm" too, as it is a cost relative to the ideal.
In short, I don't deny that the benefit-cost ratio is very low (unless taking into account the benefits accruing indefinitely after ESM-only becomes ubiquitous), but I think there is room for the idealists and the more neutralish dual-packages to collectively create a positive result in the end, especially if another kind of idealist is willing to sacrifice in making PRs for at least switch to ESM in source and distribution and others are open to the changes, but it will really be the ESM-only packages that prod change, I think.