Most of all, the form of the message reflects the underlying architecture of Windows 386 Enhanced mode.
Enhanced mode Windows kernel consists of two mostly independent layers. I am going to refer to them in this answer as the ‘supervisor’ and the ‘hypervisor’, although those terms are somewhat anachronistic: they were not used at the time to describe the design of Windows, although the terms already existed back then.
The supervisor is pretty much Standard mode Windows, and it handles most of what we think of as ‘Windows’ proper: starting Windows applications, scheduling them, drawing on the screen and handling application crashes. Displaying messages informing of the latter is the responsibility of an internal API call named
SysErrorBox; other than being modal to the entire system, the message box is a completely ordinary window, handled by the same message loop architecture as every other window in the system.
As for the distinction between error boxes that contain the ‘Ignore’ button and those which don’t, the blog post linked in the question already explains it: whether the button appeared depended on whether the crash handler is able (and willing) to skip the particular instruction which triggered the crash. Either of these can result from a General Protection Fault (which usually means memory corruption), so they are about equally severe. The ‘Ignore’ feature appeared in Windows 3.1 (in earlier versions, all crashes were unrecoverable) and existed mostly to give the user a last-ditch option to attempt to save their data and exit the program relatively gracefully. The error message instructed the user to save their data in a new file to prevent overwriting a known-good file with a potentially corrupted version (as it might very well be, given that it was written by an application in a corrupted state).
The hypervisor layer is the Virtual Machine Manager: its purpose is mainly to allow running DOS programs under Windows. Both the supervisor and each DOS box runs in a separate virtual machine; the virtual machine which runs the former is called the System VM. The VMM decides how those virtual machines map to physical hardware: it may, for example, direct writes to screen memory to update the contents of a DOS box window. Unlike the supervisor, the VMM does not understand how to draw on the screen and only knows enough about devices to know how to dispatch signals from them to the correct virtual machine. Most screen operations are handled by the virtual machines themselves; the VMM only contains just enough display drivers to be able to switch the video hardware to text mode and back. And so, when the VMM needs to communicate something to the user without the help of the System VM, that’s exactly what it does.
As others have already pointed out though, Windows 3.1 does not use full-screen text mode messages to inform of crashes: the actual Blue Screen of Death did not appear until Windows 95. An outright crash in the VMM would take the entire system down and return the user to a DOS prompt. In Windows 3.x, messages from the VMM usually relate to the rather specific job it performs: for example, it informs the user about hardware conflicts and prompts the user to switch floppies when performing dual floppy drive emulation on a single-drive system. The VMM also includes a rudimentary software hang detector: pressing CtrlAltDelete prompts the VMM to check for a Windows process stuck in a message loop and offer to forcibly terminate it. This results in the blue screen prompt featured in the question.
Blue screen prompts can be, among other causes, triggered by VxD drivers through the VxD service
SHELL_SYSMODAL_Message, although that is not quite its exact purpose — when invoked on behalf of a DOS box, it may try to display a regular message box instead, by handing over the request to the System VM.