While I agree with the general thrust of your post, I would not call these technical solutions, as they are chiefly psychological: they are designed to address a psychological problem (fear of future problems) by psychological means (changing the incentive balance by various nudges).
In other words, my hypothesis runs like this:
- A certain group of people (I call them group 1) are worried that they will unexpectedly1 need the full flexibility of Kernel code in the future and they will face unpleasant circumstances in their workplace because they will not be able to deliver.
- However, when this flexibility used to exist, despite being discouraged in the community, it was used in a number of situations where it was not necessary and better solutions existed. This is undesirable for everyone involved and part of the reason for the current restrictions. The main explanation is that it seemed easier than the alternatives.
- Suitably changing the incentive structure may allow both of these goals to be accommodated.
1 Unexpected, since if you are expecting upfront to need capabilities for which Elm is currently unsuitable, then according to the advice which is now even in the official guide, you should just pick a different technology for the project.
On a more personal note from running an Elm project in a commercial setting where the powers that be had a very begrudging approval of using Elm it had some emotional rollercoasters for me: The joy of how much easier most things were compared to the React stack we were using for other projects combined with the fear of being asked to do something for which there was no pre-existing library and suddenly I would spend 4 times as long working out the best way to hack something together. Generally these fears mostly didn’t materialise, but I can empathise with folks who feel this a lot stronger in less secure situations.