Yes, you can blame programmers for crappy code - in many cases - there is lot of it indicating that coder was on Z80 or similar CPU - doing test on data reg after moving in it (where 68000 already set flags). And many other ... But part of problems is clearly to blame DR for. Poor documentation, Trap calls are not organized well.
There is unused space in sys. variable area, some 100 bytes, + area $600-$700 is not used at all, not even on TT and Falcon. And yet, they did not place all those variables for reading kb. , mouse, joystick in that, well defined area, but elsewhere in low RAM, different locations in every TOS version. Instead it, they introduced those 9 IKBD vectors, which basically just read variable and copy in (a0). Combine it with poor docs, missing detailed explanation - and we are at SW coders forced to do dirty coding - using those sys. vars at not globally defined addresses (STOS - made by very good programmer) .
Note about that 1MB RAM machines were problem is little over top, failing on it is really crappy coding of programmers - and there are variables to see real RAM amount very easy - PhyStop. Even if it is forged, you can read Mem control shadows in sysvar. area.
TOS is not best for action games, but it is not true that is not suitable. There are plenty of very quality games using TOS calls: Starglider, almost all Silmarils games ... at least 200 top quality. Not true that no function for joystick read - and I showed in this thread how easy is to use it. Only that programmers missed it somehow in 80-es. Of course, it would be peace of cake if they put joystick read results in regular sysvar. area.
Then, something really unexpected changed, as result of bad planning: moving TOS ROM address in STE higher.
Starting to use Timer C in TOS 2.06 for Trap #1 file access calls. If Timer C is changed, it will freeze or whatever when trying disk access. Who to blame for that sudden change ? Was Timer-C reserved for future usage ? I did not see anything about it. Even if it was, programmers seen that it is unused in TOS 1.00-1.04, so they grabbed it for better work of SW. Why should not ? Because some misty future plans. Not to mention that is easy to add patch, what will restore regular Timer-C before disk access.
We can talk here for months. You can't convince me that TOS self is cleanly made. Right this mess with IKBD read is good bad example
Doing clean SW what works on all TOS versions is possible. Until it is not much complex, and does not need some special things. Then you need some direct HW access, what is not that clean, and is problem for many programmers.
Anyone remember DR Basic, supplied with early Atari STs ? Shiny example of poorly made SW.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.