On the platforms DOS was meant for the hundred or so bytes of memory wasted by creating another process (PSP + few bytes for the actual code) was significant so the simple approach of writing trivial .COM that does EXEC(COMMAND.EXE), EXIT is wasteful. DOS does not have exact equivalent of unix-style exec() so replacing the process in memory would involve either adding that to DOS or implementing it in the .COM stub, both approaches have the slight problem that there is no way to guarantee that the block of free memory that was selected by DOS for the .COM stub (and thus starts with the PSP of our process and its starting paragraph is our PID) is large enough so the EXE would fit there.
Also such .COM stub will have to be stored on the disk as separate file which on FAT16 would probably waste most of the used cluster given the expectation that it would be few bytes long stub.
NTFS gained symlink support in 2007. FAT never had it. If presented with this problem, I'd say changing the executable loader is a better solution to the problem than adding symlink support to the file system.
From my novice view, it seems like it would be generally simpler to reason about.