Reading this I again have to question the motivation for such destructive development styles and why some people actually think they are an achievable goal. How good that ZDoom's developers are not supporters of this!
ZDoom is not 'most software'. Most software does not depend on such intricate data as game resources and associated definition files. If a text editor drops compatibility with an old encoding, it'd be at worst a one-time conversion step for the affected file to be readable again.
If a programming IDE like Visual Studio changes how it maintains its projects it is also a one-time conversion step.
Same for C++ compilers. Fix the code once and it works again.
None of these things can easily be done with game data. Change the underlying fundamentals too much and it does not work anymore. So - because we cannot change the underlying fundamentals to allow the suggested 'radical change', both DECORATE and ZSCRIPT will have to produce the same data.
DECORATE is already excellent at this - far better than anything that has been cooked up by other port authors. It's a testament to its design that, despite having been heavily extended, the heart of it is still the same code from the end of 2004. So something in here must have been done very well. Why trash it? Building the new language with all the knowledge about what worked well and what did not makes a lot of sense. And the few things that weren't so great - lack if constant use in properties and states, and the generally shaky state syntax have been addressed in ZSCRIPT - so in my opinion it has done the right thing - take DECORATE and fix the issues. We all know that this would not have been possible inside DECORATE itself, it had to be something different - but being something different does not imply that EVERYTHING has to be done differently, just for the sake of it.
And in case the 'maintaining deprecated code' blurb comes again, just look at the old-style DECORATE parser. Yes, it has occasionally been modified, but that was always minor things, like making adjustments in function calls when some lower level things were changed. Outside of these and a few code cleanup passes this code has basically stayed the same for 10 years. And it still allows loading mods like Daedalus and RTC-3057 which made use of it to define some scenery objects. Note that these mods are 12-13 years old by now!
What should be done with ZSCRIPT is a cleanup of the action function list. Some are badly named, some have bad parameter ordering and some may just be redundant. Now that the lump names and the format change it may be a good time to rename things like A_CustomMissile to A_SpawnProjectile, and deprecate the old name (not remove it!)