Software Experts Ignored the Economics Of Hardware
...or "Moore was right and they were both wrong"
The biggest thing that was overlooked in this debate was the impact of CPU manufacturing technology and economics, driven by shrinking transistor sizes as expressed in Moore's Law (not surprising as though they knew a lot about CPU hardware, these guys studied and debated software, not CPU manufacturing or economics). Fixed manufacturing costs which are amortized over CPU's (e.g. ISA design, CPU design and CPU production facilities) have grown rapidly, thereby increasing the value of economies of scale; with per unit CPU costs (in terms of "bang for the buck" & "bang for the watt") plummeting, the cost of a CPU needn't be amortized over such a broad selection of functions to provide value, so computing in products with fixed function has exploded; CPU transistor budgets have grown exponentially, therefore wasting a fixed number of transistors due inefficiencies in ISA design is of no consequence.
1. CPU Scale Wins Over CPU Diversity
The importance of economies of scale has made the benefits of a ISA/CPU targeting a larger (therefore broader) market outweighs the potential benefits from design choices which narrow the market for an ISA/CPU. OS's can address larger and larger portions of the market per supported ISA/CPU, so there is little need (or even no need) for porting exercises to allow an OS ecosystem to thrive. The problem domains ISA's & CPU's target tend to be so broad that they mostly overlap, so for any software beyond a compiler, the size of porting exercises has also diminished. Arguably, both Torvalds & Tanenbaum overestimated the portion of kernel design and implementation that now needs to be ISA or even CPU specific. As Tanenbaum described, modern OS kernels do abstract out the distinctions between CPU's & ISA's. However, the CPU/ISA specific code in modern OS's is much smaller than a microkernel. Rather than implementing interrupt handling/scheduling, memory management, communication & I/O, these non-portable bits address only a tiny fraction of the implementation of those services, with the vast majority of the architecture of even these core OS functions being portable.
2. Open Source Won the Battle, But Lost the War
More bang for the buck means that a larger share of computing is performed by fixed function products, where the ability to modify the product is not part of the value proposition for the customer. Now ironically, open source has flourished in these fixed function devices, but more often than not, the benefits of those freedoms being realized more by those making the products rather than end users (which actually was true of the software market even back then: Microsoft was a big consumer of open source software, but their customers were not). Similarly, one could argue that open source has struggled more in the general purpose desktop space than anywhere else, but as the web and cloud computing has grown, desktop computing has increasingly been used for a narrower purpose (primarily running a browser), with the remaining functions running in the cloud (ironically, primarily on open source platforms). In short: open source does really own the general purpose computing space, but the market has become more sophisticated; computing product packaging less often stops at general purpose function, but continues along to product intended for fixed functions, where much of the advantage of open source computing is in conflict with the product goals.
3. 2n Growth Means Fixed k Savings Are Not Important
The exponential growth of transistor budgets has brought with it the realization that the transistor budget cost of a CISC architecture is almost completely fixed. RISC's strategic advantage was that it moved complexity out of the CPU's instruction set and in to the compiler (no doubt partly motivated by the fact that compiler writers benefited far less from complex ISA's than human developers coding in assembly, but compilers could much more easily reason mathematically about, and therefore exploit, a simpler ISA); the resulting transistor savings could then be applied to improving CPU performance. The caveat was that the transistor budget savings from a simpler ISA was mostly fixed (and overhead in compiler design was mostly fixed too). While this fixed impact was a huge chunk of the budget back in the day, as one can imagine it only takes a few rounds of exponential growth for the impact to become trivial. This rapidly declining impact combined with the afore mentioned rapidly increasing importance of the CPU monoculture meant a very small window of opportunity for any new ISA to establish itself. Even where new ISA's did succeed, modern "RISC" ISA's are are not the orthogonal ISA's described by the RISC strategy, as continued growth in transistor budgets and broader applicability of SIMD processing in particular has encouraged the adoption of new instructions tuned for specific functions.
4. Simple: Separation Of Concerns. Complex: Separation Of Address Space.
The modern Linux kernel (along with most other kernels) fits the rather loose definition of a macrokernel and not the rather than the narrow definition of a microkernel. That said, with its driver architecture, dynamically loaded modules and multiprocessing optimizations which make kernel space communications increasingly resemble a microkernel's message passing, it's structure more closely resembles a microkernel design (as embodied by Minix) than the macrokernel design (as embodied by Linux's design at the time of the discussion). Like a microkernel design, the Linux kernel does provide generalized communication, scheduling, interrupt handling, and memory management for all other OS components; its components do tend to have distinct code and data structures. While modules are dynamically loaded, loosely coupled pieces of portable code, that communicate through fixed interfaces, the don't employ one remaining property of microkernels: they aren't user space processes. In the end, Moore's Law ensured that issues motivated by hardware concerns like portability (a concern of Tanenbaum's) & performance (a concern of Torvalds') diminished, but software development issues became of paramount importance. The remaining unrealized advantages that a separation of address spaces could provide are outweighed by the additional baggage imposed on the OS software due to design limitations and increased complexity of component interfaces.
Interestingly, what has been a strong trend is the emergence of the hypervisor, which much like microkernels, abstracts out the hardware. Some claim that hypervisors are microkernels. Hypervisor architecture is different though, as responsibilities meant to be owned by microkernels are handled by the "guest" kernels sitting atop, with hypervisors multiplex between them, and the hypervisor abstraction is not generic messaging and memory address space, but predominantly actual hardware emulation.
In Conclusion: The Future Favours Those Who Adopt Least Strict Semantics
*..or "nitpickers suck at predicting the future"
In practice a lot of the rightness/wrongness in the debate is a matter of semantics (and that was part of what Torvalds was arguing and IMHO Tanenbaum failed to fully appreciate). It's hard to make precise definitions about the future because there are so many factors outside of the argument that can come in to play; looser semantics means your predictions are a larger target on the dartboard than the other guy's, giving you way better odds. If you ignore semantics, the arguments advanced by both Torvalds and Tanenbaum were right about a lot of things and wrong about very little.
tl;dr
Most ISA's don't fit the semantic definition of RISC, but harness most of the design advantages which were distinctive of RISC CPU's at the time; the amount of OS which is CPU specific is less than Tanenbaum expected, let alone Torvalds; open source does dominate general purpose computing, but the consumers of that market are now primarily those who package computing in to more fixed function products where much of the benefit of open source software isn't realized; separating out OS function across address spaces didn't prove to be beneficial, but separating out OS function across "virtual" hardware has. If you want to claim your predictions proved right, leave yourself as much semantic maneuvering room as possible, just like Mr. Torvalds.
P.S. A final ironic observation: Linus Torvalds is one of the strongest proponents of keeping as much new functionality as possible up in user space and out of the Linux kernel.
Linus "my first, and hopefully last flamefest" Torvaldswhich obviously failed to come true as well :)