Why are you trying to convince or gaslight everyone into believing that the developers are too lazy to update the plugins?
I'm afraid I genuinely have no idea where you got the impression I thought addon developers are lazy. I have been talking about how I am keenly aware of just how much work this is going to create and how disruptive it is going to be. We are asking addon developers to co-operate with us through the transition and I am writing a lot on the forums here to explain the reasons for this, as it is fair that we should have to justify why we are doing something so disruptive.
WackyToaster - regarding the "group handler" addon: I'm afraid that is the very reason we had the warning in the SDK. It could break at any time. If it's worked for several years already, that is absolutely no guarantee at all it will continue working even one more week - unless we have a proper API with encapsulation. We could rename some variables or fix a bug in the engine, and your addon will be broken. It could break repeatedly, every few weeks, for a year or more, and then ultimately break permanently, causing untold disruption along the way. This is already happening with other addons and will continue happening. Given that in the long run pretty much all parts of the engine are eventually changed or upgraded, all such addons accessing internal details are likely to eventually break. Part of the point of this project is rather than sit around and wait for disaster to eventually strike for all these addons at random and unpredictable times, we're managing the process up-front with a published timetable for what action will be taken so everyone can plan ahead and the problem can be solved once and for all.
By ignoring the warning in the SDK, I am afraid you must carry some of the responsibility. We did say undocumented features could be removed at any time. So we reserve the right to remove all those features, break your addon permanently, and say "tough luck". Then all the customer's projects using the addon are broken and it was because you ignored the warning in the SDK. However, we are not doing that: instead we are laying out a timetable and doing what we can to try to make the transition smoother. If people really need your addon and removing it is infeasible, they'll have to stay on old releases (possibly a future LTS release) until they finish their projects; if it really is going to cause enormous disruption, we might add necessary features to the Addon SDK v2 to allow you to port your addon, depending on a judgement of the situation, feasability of maintaining the APIs, etc. However, at the end of the day, we reserved the right to permanently remove all those features, and we did warn you of that.
The industry came up with encapsulation decades ago precisely to solve this problem. Experienced developers know that if outside developers get access to internal details, of course it ends in disaster, of course it makes a huge mess for everyone. All other tools use encapsulation for an addon system to avoid this. As I've explained, the addon SDK lacked encapsulation mainly for historical reasons as JavaScript had poor support for encapsulation in the past. Either you learn the lessons of history and respect encapsulation, or you disregard them, and you learn the hard way as it invariably ends in disaster.
Given all this, I have to say, in my view it was unwise to develop such addons. Adding a few small handy features via accessing internal details, at risk of causing disaster and potentially ruining everyone's projects in the long run, is just not worth it. The alternative may be some more clunky event sheets and perhaps a slightly less smooth workflows, but people's projects keep working indefinitely. In the long run that's the better outcome. In my view, fully understanding the reasons encapsulation exists and the severity of the risks of bypassing it, I would not even consider trying to bypass encapsulation, under pretty much any circumstances at all short of a genuine emergency where not acting is also sure to cause a disaster. Anything else at all, even significant inconvenience, is better. The extent of the disaster it risks must be avoided at all costs. This is why, despite all the disruption, we believe it is absolutely essential that we move to a new addon SDK with much stronger encapsulation. Either we have planned disruption now, or we have never-ending continual unexpected disasters of increasing severity for years to come.
I am also aware many addons are well-behaved and have never accessed any internal details. I do regret that these addons still need updating to the new SDK. I hope that by explaining the situation in this much detail, I am highlighting how important this work is and why it's for the best in the long term.