I'm not sure about the advertising, but OS/2 1.3 really was extremely stable. Later versions were also quite stable, though it never seemed to me that any of the others quite matched the last of the 1.x series.
Most of that came from using the processor's protected mode, which most other OSes that were in wide use on PCs at the time didn't use.
In particular, most people on PCs at the time ran MS-DOS, which ran in real mode. In real mode, all code running on the machine had access to all memory locations, so it was entirely trivial for a normal program to overwrite things like the operating system or the interrupt table. The interrupt table was especially vulnerable because it was right at the beginning of memory, so writing via a null pointer would overwrite more or less arbitrary interrupt vectors.
By the time of OS/2 1.3, many MS-DOS users did use some sort of memory manager (e.g., 386^Max). In this case, MS-DOS was technically running in a V86 process, and the processor itself was running in protected mode. For better or worse, however, unless you also ran something else as a "supervisor" (e.g., DesqView), the fact that you were in protected mode was mostly hidden, so the system provided (at best) a minimal improvement in stability over actual real mode.
Since then, use of protected mode has become ubiquitous. While it's still possible to crash a computer (e.g., Windows' notorious blue screen of death) there's really no comparison to how things were under MS-DOS.
I'm not sure it was ever used as the basis of an actual attack, but others have mentioned OS/2's queuing problem, but nobody's explained what the problem was.
As events arrive from the keyboard, mouse, etc., they're put into a queue. Then the PM figures out where they should be routed, and the target process removes the event from the queue. Lather, rinse, repeat.
The problem arose if a program simply quit removing its events from the queue. There was one queue shared between all PM processes, so if one didn't retrieve its message, nobody else could retrieve theirs either, and the system quickly ground to a halt.
For Windows NT, Microsoft changed the architecture just a bit, to prevent this:
In this architecture, the OS kernel code removes events from the shared queue, sorts out where they should go, and deposits each in the event queue associated with the proper process. If a process quits processing its events, its own queue will back up (and the user will get an error message), but it won't affect any other processes.
Windows certainly has its share of problems as well, but this particular problem definitely is not one of them (unless you're looking at Windows 3.x/9x/Me, which was an entirely different beast).
