Probably most is not aware that TOS consists from 2 clearly separated parts:
1. The GEMDOS part, what actually contain: early HW initialisation (after power on, reset), BIOS, XBIOS, GEMDOS
 and character sets (8x8 and 8x16 px) - latest is placed after AES part, from for me unknown reason.
2. The AES part, what contain AES (GEM) self, then Desktop. At the end are some RSC structures for Desktop, file selector.

AES part, Desktop never calls some subrutine from GEMDOS part directly - all it goes via system calls, so Traps - #1,2,13,14 .
That's very good - thanx to it, we can combine GEMDOS and AES from different TOS versions.

As is known, most of TOS code is done in C, in ASM is done mostly low level HW accessing part. Myself think, that it was choice what seemed then as only reasonable, and they just followed usual way, used with Intel 16-bit CPUs (8086) .
But, it is now clear, that Atari and DR (Digital Research) did not have good enough C compiler in those years (at 1984 to 1992) - hmm... maybe the Orwell's year was the problem :-)
They had problems to fit TOS in provided ROM space (192 KB) - in big part just because not efficient C compiler. And maybe because programmers were not experienced with MC68000 CPU coding.  Not only that code generated is not much efficient, considering space and speed, some simple things were done not optimal. And that could save plenty of space.
Addressing:  in TOS versions 1.xx  there is no short addressing used at all . With 68000 normal addressing is 32-bit. But, if address is in range 0-$7FFF or  eqaul to and above $FFFF8000 you can use 16-bit addressing. That saves 2 bytes per addressing. And since there is plenty of it in code, that can save some 4KB only in GEMDOS part - and it is what is possible with TOS 1.04 and 1.06/1.62 (which are pretty much the same). In case of 1.04 4KB means a lot, since there is only 1KB free space in org.
What happened in 1989, when 1.04 and 1.06 were released ? 192KB for 1.04, and that was not enough for straight code. They needed to use Line-F emulator to save some space. With 1.06/1.62 it was better, since there was 256 KB space in STE.
Looking in TOS 2.06 code says that most of it is optimised, so 16-bit addressing used when it is possible. Little funny that then was no real need for it in 256 KB TOS ROM.

And we are at for me biggest mistery in TOS:  FAT16 filesystem code, with Big partition support (over 32 MB), and yet 16-bit recno (called logical sector too) - sector address in fact. There are some, mostly incomplete TOS sources available.
And there stays for recno variable: "it should be 32-bit" . Great ! Then why is not changed to it ?
Well, my latest founds (end of June 2018) indicate that used Alcyon C compiler was bad with unsigned integers even in 1991. 
What is really something even hard to believe. What developers of it did over 6 years ? Of course, it could be solved even with that flaw of compiler, at some extra work.
What is sure is that it did not happen. Not in Atari. Some did it - MagiC first, most likely. And as last - I did it, but not in C sources, but in disassembled S 'source' . That way had it benefits, but was for sure much harder than doing all needed corrections in C. Main benefit was that I needed to look how to manage GEMDOS code length same, or shorter, since right after it comes AES, what I did not want to change or move. As I seen all those not necessary long addressings, normal was to go on optimising. It needed some more accurate disassembling (labels instead constants in some 10 sections, actually) - and that resulted in 4KB shorter code, even with added things.

Now, in 2018, I can only think that reason for was lack of motivation of employees. I hope that we will hear something from someone involved in it, some day.
Adding at end of June, 2018: I think that I will not bother anymore myself with trying to contact someone of people, which worked at Atari, maybe DRI that time. That's just too frustrating, and even if you make someone to respond, that's usual short answer - maybe will talk, will see ...  Then nothing.  So, forgive me if there are some mistakes and too much speculation. That's all what I can to provide.  I like to know what and why happened, and if people talk not, there is something what talks: code in TOS .
I seen lot of it there, what could be done better, often with really simple solutions:

More optimisations: digged little more in TOS, and seen that AES RSC and Desktop RSC + Desktop.inf template are copied 1 to 1 in RAM, and that's some 16 KB in case of 1.04 and 1.62 - so they are in ROM and RAM at once. Indeed, some parts must be in RAM, because of changed coordinates, flags, then editable txt, but there is lot of static txt, what could be accessed from ROM. After disassembling AES part, I seen that it is simply copied all 3 together. And that's good for packing. So, I packed that section (what is at very end of TOS ROM), and that went shorter 10 KB.  And was able to optimize AES code too - shorter 2 KB. So, at the end, I was able to make TOS ROM code for 1.04 and 1.62 shorter for 16KB. Without removing anything !

To add that in 2.06 it is done better - static parts stay in ROM, no copy to RAM. And there is more important, since all it is longer.

This opens whole new perspectives - there is lot of free space now even with 1.04. And it can now be modded to work with 68020-30 accelerators. It's not possible with 1.04's AES, because line-F emulator. But now we can use Desktop of 1.62 in 1.04 (they are practically same, except line-F). It is longer some 8KB because not using line-F, but straight subrutine calls - and now, there is space for it in 192KB ROM space. I have already 1.04 modded for long stackframe, so that can be assembled in short time. And of course, there will be still place for improved FAT16 and Virtual Floppy.
Next thing to do is little 'artwork' - changing Desktop icons, to clearly indicate modded TOS v. Sorry, no plans for some multi color icons - that would need more RAM and AES extensions.



More can follow, some day :-)





    PP,  May  2018.