IIRC using trace serves two purposes, both related to stability and performance:
Improving command detection
With TRACE enabled BASIC prints the line number `prefixed by a '#' character and suffixed by a space whenever a new BASIC statement is executed. Following that trace output BASIC.SYSTEM can detect whenever a new statement starts. If the next printed character is the DOS command character (*1) then the following output, until line end, will be checked as (Pro)DOS command.
This solves an issue DOS had with commands following a 'dangling' PRINT. To avoid unintended command detection, or swallowing of binary print data, DOS looked for its command indicator only after a previous CR. If the last print before a DOS command did not end with an CR the command was not detected . Such errors could be quite hard to detect within the usual spaghetti code BASIC.
By using trace this was avoided. Each and every Print that started with the command indicator would be noticed and acted on (*2)
Improving speed due better memory handling
Applesoft isn't a bad design (*3) per se, but it got some quirks. One of them is string storage. The strategy for string management is to use a heap where each newly created or modified string is simply put on top, while any older version is left dangling. The heap only gets reorganized (compacted) when there is no more free heap space at the top (*4). Usually not a bad strategy, as it reduces shovelling data in memory by not doing it until really needed and then in a more efficient fashion.The process is called garbage collection and incredible inefficient in Applesoft. Depending on fragmentation running it can take anywhere from several seconds to more than a minute. Usually more to the upper end.
So far no issue, as Applesoft is still Applesoft, right? Yes, it is, but it gets worse under ProDOS as now way less memory is available. ProDOS plus BASIC.SYSTEM needs about twice as much RAM as DOS 3.3. Moving ProDOS into the language card still leaves any II with about 2 KiB less free memory due the size of BASIC.SYSTEM, file buffers and alike which all need to reside in standard memory.
As a result the same program will experience more often a garbage collection under ProDOS than it did under DOS. We're not talking 'Hello World' type programs or such without much string handling, but common interactive programs, or data handling programs.
To elevate this BASIC.SYSTEM brings it's own, way more efficient garbage collection for Applesoft (*5,6). There's just the minor issue that when Applesoft issues a garbage collection it will always be it's own, as that's hard coded in ROM. No way around (*7).
To avoid this BASIC.SYSTEM needs to do a garbage collection before Applesoft decides to do so. This is where TRACEing again comes in handy. BASIC.SYSTEM gets called every line and statement within, so no problem to do a garbage collection when needed. To do so it checks the remaining free space (comparing a ZP pointer against a saved value) at the begin of each line and starts the cleaning just before Applesoft would :))
As a result, string heavy programs run faster under ProDOS despitte having less memory :))
*1 - $04 aka CHR$(4) or D$
*2 - Of course this created, depending on program structure, some new issues with binary output - You can't have everything.
*3 - well, it's MS Basic, so let's skip that discussion :))
*4 - Yes, I know it's growing from memory top downward. This is about the logical top of the heap.
*5 - While Applesofts garbage collection can be invoked using
PRINT FRE(0), ProDOS' version is called by doing
PRINT CHR$(4);"FRE" withing a program
*6 - The difference is rather easy to detect, as ProDOS'
FRE and Applesoft's
FRE(0) can both be used at will. Write a program doing a bunch of string operations - like appending an empty string to some existing one in a loof (just make sure it doesn't fill up all memory) and then issue either version.
*7 - Also no way to move Applesoft into Language card and patch it there, as that space is already used by ProDOS.