I think one reason ZDoom takes flak where Boom doesn't might be that by and large everyone who still plays and maps for Doom uses an engine that supports removed limits and Boom features, but there is a significant minority who don't use ZDoom as their primary engine. Thus, most players don't notice Boomisms (indeed Doom+ aka limit removal could be considered one huge Boomism) but this minority of non-ZDoom users are sensitive to Doom/Doom+/Boom maps that turn out to only work in ZDoom, and complain loudly about them. Those whose primary engine is Chocolate Doom aren't sufficiently numerous or vocal enough to fill up the forums with complaining about wads that don't work with it. :)
Totally agreed on Boom, I've mentioned that before, ZDoom gets too much shit for changes when Boom was just as bad about forcing changes on by default, and didn't even give level designers a way to specify the behavior their maps needed.
The "classic trio" of ZDoomisms (i.e. by far the three most common types, common enough for PrBoom+ to have implemented workarounds; implicit manuals, implicit passuse, and hanging solid bodies in tall sectors - the latter of which to be fair is not ZDoom-specific but appears in any engine that does proper thing height clipping) are all changes that are on by default in ZDoom but require some effort to achieve in Boom (e.g. by deliberately turning the passuse flag on, or using the right type of generalized linedef). It can and has been argued that their appearance in maps is due to poor testing on the part of the map designer, but I believe ZDoom could do more to help him there. On the other hand, as Graf Zahl says, there are wads that depend on these behaviours being on by default (tautologically, those wads which have ZDoomisms...)
I think another reason why ZDoom takes flak might be that it is here, now, currently evolving, and its developers are here, now, and you can moan at them; whilst Boom has become a "standard", set in stone by not having changed much at all since 1998 (save for a few things like increased limit removal and support of ZDBSP nodes, Boom game physics as a standard has remained more or less untouched; PrBoom's compatibility levels and Eternity's demo version numbers exist to enable additional features without affecting the "core").
I've toyed with the idea of only allowing ledge dropoff when the monster is being moved by a conveyor floor or affected by wind or something. I can't think of any reason why this wouldn't work but haven't actually tried implementing it anywhere yet. On the other hand any such change would have to go into a new compatibility level, so nobody would use it. ;)
Thanks for the explanations, too. I knew about the other two, but was never aware that monsters getting shot off ledges was the result of adding scrolling floors.