The thing that gradually doomed the UNIX workstations was Microsoft Office. Corporate managers really wanted their engineers to be able to read and write Word, Excel and PowerPoint documents, and were annoyed that engineers couldn't do that on their workstations, and even worse, weren't concerned about it. Giving them a second computer for Office was obviously expensive, so when Windows PCs became capable of running high-end engineering software, that was what all the customers demanded.
This need was understood long before Windows PCs actually took over. The head of my department at work had understood it in 1996, although he over-stated it and didn't convince me at the time.
Before Intel shipped the Pentium Pro in November 1995, all the RISC Unixes had major performance advantages over PCs. It was reasonably straightforward for an ISV to offer the same software on several of them, since they all used Unix, similar dialects of C and C++, and X-Windows for GUI.
The Pentium Pro was the first mass-market processor to use the modern technique of breaking down more complex instructions into micro-operations and having a "pool" of them that Functional Units could grab operations out of to execute when the data they needed became available. It was much faster than the Pentium. The MIPS and SPARC processors of the time suddenly looked vulnerable. One company that had been set up to offer fast MIPS-based Windows NT machines abruptly changed to using Intel.
The original Pentium Pro's impact in the general Windows market was limited, because it ran the 16-bit code that was common in Windows 95/98 rather slowly. That was utterly irrelevant for competing with UNIX workstations, where all the relevant software was fully 32-bit.
The advent of 64-bit
This actually started before the Pentium Pro, with the DEC Alpha, but didn't become important until the price of memory was low enough that having multiple GB of RAM was sensible. It marked an important change: memory limits became a soft cap rather than a hard cap.
With 32-bit addressing, using more than 4GB of address space in a process (with inevitable subtractions for the OS) was annoyingly hard work. People who'd had to work with EMS and XMS memory under MS-DOS were very reluctant to use PAE or bank-switching: it was clear that 64-bit addressing would be a better solution, and that it was on the way.
So with 32-bit addressing, there was a hard limit on your "document" size. This wasn't usually a traditional document, but a CAD, CFD, or other kind of "model." With 64-bit, you could make bigger and bigger models. They got slower when you exhausted the physical memory of your machine, but you could buy more RAM.
The Itanium fiasco
The long-term significance of Itanium was that it disrupted the development of the main RISC architectures:
- MIPS development stopped for several years, and never caught up again.
- Alpha was killed off.
- PA-RISC was replaced by Itanium.
- SPARC and POWER only had brief slowdowns, which is part of why they're still going.
AMD did a good job
One of the reasons Itanium was so unlike x86 was so that it could be patented up to the eyeballs, and none of it would be subject to AMD's x86 license. AMD could not build Itanium-compatibles, so they had to design something to compete with Itanium. They did that well, and Intel made several mistakes with Itanium design and product management. Intel ended up having to build AMD-compatibles.
Microsoft enforced cross-compatibility
Apparently - this is from a senior AMD person in 2005 - Intel wanted to build a 64-bit x86 that was not AMD-compatible. Their intention was to force software vendors to do separate builds for Intel and AMD, in the hope that they would not bother with AMD software, and drive AMD out of the market.
Dave Cutler of Microsoft responded that they already had 64-bit Windows working nicely on AMD64, and while they could not prevent Intel making their processors incompatible, they could and would refuse to offer Windows for such processors. Intel had to back down.