I suspect that they're alluding to the fact that DOS was more of a program loader than an OS and that once it loaded your program it was your program that was in the driver's seat. BUT there are subtle issues with drivers and networking still.

I know that, but unless you can 100% guarantee that the application was clean from any kind of DOS interrupt calls, there are zero guarantees that it wasn't DOS, one of the drivers or the pseudo multitasking TSRs that were the culprit, there is no way to assert that the application was the one at fault.

DOS was simple enough that it can be considered essentially bug free. And in an embedded setting there are not going to be TSRs (you just boot directly into the application) and probably no DOS calls during the runtime. You would only use disks for special operations such as software updates.

Ah such a lucky one, never crashing DOS code, I guess you never used MS-DOS 4, nor had the experience of porting code across PC-DOS, MS-DOS and DR-DOS.

Some DOS versions were better than others. But often the cause was non portable code on the applications. That wouldn't apply if the DOS version is frozen.