The existence of a command line switch is good and should mean that the behaviour is documented (and likely to stay the same).

But the important thing here is that there are no general rule how embedded compilers handles the main() function. Because of this, the developer should always take the safe route. Then it doesn't matter if main() is called or jumped to. And it doesn't matter if there is a catcher loop at the end. Or if 'return' statements are caught and changed from return to a jump to the catcher loop. Or if main() will be followed by 0xff to the end of flash. Or if main() is followed by a jump to the start of main() again. Or a loop that activates the watchdog and then waits for a watchdog reset. Or possibly any other alternative.

Engineering is about making sure. Don't pick up a random bolt that is "strong" enough and use just like that. Also think about galvanic reactions when mixing different metals. Or protection from acid environments. Or fatigue responses in different metals when subject to vibrating load. Or what torque that should be used to keep everything tight even in hot or cold weather without breaking the bolt from the thermal expansion/contraction. Or what thread size that is best suited for the task with respect to strength, precision, ...

Keeping track of the available execution paths is one of the fundamental aspects of sw engineering. Don't running out of main() helps if the code gets ported to another embedded compiler. And it will not surprise another developer who sometimes in the future have to take over the code.