Consider these commands.

C:\examples>type file.c
int a

C:\examples>cl2000 file.c
At end of source: error: expected a ";"
1 error detected in the compilation of "file.c".

>> Compilation failure

C:\examples>echo %errorlevel%
1

C:\examples>cl2000 file.c

C:\examples>echo %errorlevel%
0

C:\examples>cl2000 -@\bad\path\no_file.txt file.c
>> ERROR: Cannot open command file '\bad\path\no_file.txt': No such file or directory

C:\examples>echo %errorlevel%
0

The first command shows the contents of a simple C file. The semi-colon is intentionally left out. The second command builds it. The third command shows the exit code seen by Windows is 1, for error. With commands not shown, the semi-colon is added. The fourth command shows a clean build of the file. The fifth command shows the exit code seen by Windows is 0, for success. The sixth command builds the file again, but intentionally refers to an options file that does not exist. The last command shows the exit code seen by Windows is 0, for success, even though an ERROR diagnostic is issued.

In the actual use case, the path to the options file is auto-generated by a makefile. Because of user error, this path is incorrect. But the build still succeeds. The user sees the error only by inspecting the build log.  It is easy to see how this error could go unnoticed.