> The author keeps building up to this massively different, otherworldly system, and then just finishes without ever answering.

Yes, it's a weak article.

So, what do mainframes have that microcomputers don't?

- Much more internal checking.

Everything has parity or ECC. CPUs have internal checking. There are interrupts for "CPU made a mistake", and OSs which can take corrective action.

- Channels.

Mainframes have channel controllers. These connect to devices on one end, and the main CPUs and memory on the other. They work in a standardized way, independent of the device. The channel controllers control what data goes to and from the devices. Sometimes they even control what a program can say to a device, so that an application can be given direct device access with access restrictions. This would, for example, let a database talk to a disk partition without going through the OS, but limit it to that partition. The channel controllers determine where peripherals put data in memory. Mainframes have specific I/O instructions for talking to the channel controllers. Drivers in user space have been around since the 1960s.

Minicomputers and microcomputers, on the other hand, once had peripherals directly connected to the memory bus. Programs talked to peripherals by storing and loading values into "device registers". There were no specific I/O instructions built into the CPU.
Some devices accessed memory themselves, called "direct memory access", or DMA. They could write anywhere in memory, a security and reliability problem.

Microcomputer CPUs haven't worked that way for decades. Not since the era of ISA peripherals. But they still pretend to. Programs use store instructions to store into what appears to the CPU is a memory block. But that's really going to what's called the "southbridge", which is logic that sends commands to devices. Those devices offer an interface which appears like memory, but is really piping a command to logic in the device. On the memory access side, the program stores into "device registers" which tell the "northbridge" to set up data access between devices and memory. Sometimes today there's a memory management unit between peripherals and main memory, to control where they can store.

The end result is something more complicated than a mainframe channel, but without the architectural advantages of isolating the devices from the CPU. Attempts have been made to fix this. Intel has tried various types of I/O controllers. But the architecture of Unix/Linux isn't channel-oriented, so it just adds a layer of indirection that makes drivers more difficult.

(Then came GPUs, which started as peripheral devices and gradually took over, but that's a whole other subject.)

- Virtual machine architecture

The first computer that could virtualize itself was the IBM System 360/67, in the 1960s. This worked well enough that all the System/370 machines had virtual machine capability. Unlike the mess in x86 world, the virtual machine and the real machine look very similar. Similar enough that you can load an OS intended for raw hardware into a virtual machine. This even stacks; you can load another copy of the OS inside a VM of the first OS. I've heard of someone layering this 10 deep. The way x86 machines do virtualization required adding a special layer in hardware underneath the main layer, although, over time, it's become more general in x86 land. Arm AArch64 considered virtualization from the start, and may be saner.