I can’t find it in the spec right now, but it seems that I read in it somewhere that crashing (i.e., program termination) is not permitted in the case of runtime GL errors, but that what actually must occur in the case of runtime GL errors is generally unspecified. So, a white fragment resulting from your first assert example is a reasonable response.
In the case of your second assert example, you have it execute an infinite loop. Not surprising that everything will seem to freeze when you enter an infinite loop. There is no interrupt-driven timesharing operating system running on the GPU to handle escaping from infinite loops.
As far as your whole computer becoming unusable, there is probably some place in the GL driver (which runs on your CPU, not on your GPU) that is waiting for some signal from the GPU after you issue a draw command. Entering that infinite loop on the GPU will ensure that required signal never arrives. For such cases, the driver writers could place time limits on various places where they wait for hardware signals. They’ve probably never created a test case where they executed an infinite loop on the GPU. Their rationale would probably be that to implement such code will just slow the driver down all the time under all conditions and make it more complex just to handle a situation that should never occur. I can’t say I’d argue against that rationale.