This reply is mostly just reminiscences, but my impression is that you've been far too quick and far too anecdotal in being dismissive.
Five years before Y2K there was a similar circumstance known as the Pentium FDIV bug - Wikipedia (it wasn't called that at the time - I forget what we called it then). It affected the FPU. Depending upon the required precision and how you did your math (some approaches are more prone to accumulating error than others) the bug either was or wasn't serious. If you were flying spacecraft or designing bridges it was serious. Very serious.
Ten years before in the mid-80's I worked for one of the two major workstation companies, and we suffered our own version of the Y2K problem because we used the Motorola 68000 family of microprocessors which in 1987 (or thereabouts) released a faulty new generation (I no longer recall any details). This hardware bug got very little attention, as did my own suggestions to upper management that we take it very seriously in case, God forbid, someone used our workstations to design spacecraft. Nothing bad ever happened and the problem was fixed after about six months. I can find no mention online today of this bug.
To err is human, and mistakes are inevitable in any human endeavor. Some mistakes end up having no severe consequences, but that doesn't mean the dangers and risks were not very, very real. Most of the time the care and precautions we take are sufficient and things work out, but sometimes they don't, and then astronauts die and bridges collapse and buildings topple and oil platforms sink and so forth.
My group had software in the field the night of Y2K. My company knew how exposed all our software was and we had done our best to fix it, but across the entire company we had millions of lines of code, and the possibility that we hadn't fixed it in some crucial place was gut-wrenchingly clear. It was a great relief when morning came and the phone had not rung.
When you roll the dice and don't throw craps that doesn't mean the risk that you could have thrown craps wasn't very, very real. Roll the dice often enough and they will eventually come up craps.
Back around 1986 there was a book that received a great deal of attention in software quality circles whose author and title I no longer remember. The book argued that software companies were paying far too little attention to quality and that it would eventually have dire consequences. The book anticipated that in the future some programs would have extremely high numbers of installations and described disastrous scenarios of companies releasing buggy software and then receiving millions of bug reports, refund demands, and lawsuits.
What the book didn't anticipate but that became clear within a decade was that extremely high quality software often isn't needed because in most circumstances "good enough" software will do. And that's what we mostly have today, as any user of cell phones and websites can attest. Most people not in the industry blame themselves when they can't get a cell phone or website to work, which works in the industry's favor.
Companies today with large software distributions often protect themselves from dealing with run-of-the-mill bugs by making bug reporting extremely difficult or even impossible. I probably file bug reports on some piece of software about once every couple months or so, and I never hear back from anyone, other than a "thank you" type message, and maybe a reference number. For many companies I can't even figure out how to file a bug report. An insurance company I use provides no way to file bug reports or give feedback about their website, just one of the bugs I wish I could tell them about. Of course, they probably consider it a feature.