It feel counter-intuitive to me to have a batch file just ignore the rest of the content it I invoke another bat file without using call.
Is there a documented reason why they system was designed this way?
Simply resources. Keep in mind, DOS was created to run on machines with less than 64 KiB of RAM (*1), so everything was kept tight (*2).
A Command.com has only provisions for running a single batch file - that is it has only one buffer to hold one file name and a position within(*3). Whenever a command was found to be a batch file, the name entry was replaced by the newly found one and the position counter reset.
To allow nested execution of batch files it would need to maintain a stack of buffers, which would take up much wanted space. Nested execution was introduced with DOS 3.3.
If needed the same could be reached by opening a sub-Shell by executing another Command.com, which would bring its own buffer and thus being able to run another batch file:
COMMAND /C another.bat
When that batch file ended the sub-shell would as well quit and return execution to the previous one. This was also way in line with the idea to develop DOS toward a Unix like environment.
Except the additionally needed resources for the new shell were a quite negative effect. Under PC-DOS 2.0 each level did eat up about 3 KiB:
(Disk statistics removed to reduce size)
Thus DOS 3.3 added a way to execute a nested job by 'calling' it. Introduction of the new
CALL keyword was needed to avoid screwing existing batch jobs based on chaining.
*1 - Minimum RAM for DOS 1 is 32 KiB, 48 for DOS 2.x and 64 for DOS 3.x. though, useful operation might need a bit more :))
*2 - In fact, having full batch processing as a build in feature was already a step forward from CP/M where batch files had to be prepared by external
SUBMIT command, followed by a system reset after which CCP expected the batch file on the A drive, all of that working somewhat like a AUTOEXEC.BAT :))
Further to allow batch programs to receive user input another program,
XSUB had to be started by the batch file. So yes, even the modest features of DOS 1.x batch files were a huge step forward.
*3 - To reserve resources Command even closed a batch file when a program was executed and (re)opened it afterwards, thus freeing an entry in the System File Table (At least since DOS 2.0).
CALLwas introduced in MS-DOS 3.3 so before then that was just the way it was. You could use
COMMAND /Cto run another batch file and return but after returning you would not get back any changes to environment variables etc so of limited use.