And sure, x86 might be easier to understand, but it's not the original PoP. That's what this is about, not just the code.
I happened to be in the office of someone who was doing language translation on the PC version of PoP at the time; He had a copy of the source code for that, and it was C.
That was twenty years ago. I only got a glimpse of one screenful of code, but I remember feeling special for that nonetheless :)
In other words, I don't agree that 16-bit real mode is much better. Now, mdern x86_64 code is starting to get tolerable, with more orthogonal register, for example. But I'd rather chew off my own hand than be forced to write any large amount of 16 or 32 bit x86 assembly....
Then again, I'm horribly opinionated about programming language syntax...
Everything has warts (and x86 more than most). But don't pretend that ARM is clean. Or VAX (integer polynomial instructions? Non-IEEE floating point what now?). Or MIPS (A branch delay what? Multiply outputs to a separate register?). Or even 68k (let me puke garbage on your stack, I'll just tell you how much room you need).
It's that it's horribly ugly and full of warts.
The biggest issue I have with x86 is not even trying to make things orthogonal (until x86_64, which does a tolerable job cleaning up a lot of the mess).
Some of it could probably be improved simply by ditching the syntax, and renaming stuff and pretending a lot of the rest simply doesn't exist, but you'd be left with something that looks very different from a typical x86 assembly listing..
But some stuff you don't avoid unless you go 64 bit: The registers alone gives me gives me hives, starting with the naming convention, where the M68k for example is straight forward: D0 through D7 = data registers. A0- A7 = address registers. For a lot of things they can even be used entirely interchangeably.
No addressing parts of the registers with special names, or mumbo jumbo restrictions on what can be done with different registers (that was excusable when the 6502 was a viable competitor, but even that followed clear and simple rules (Arithmetic on the accumulator (A), indexing with the X and Y registers) and didn't layer complexity on top of complexity. Bank switching / segments? Nope, we don't clutter the CPU with junk like that. Either you use a memory address or IO lines (or, as it happens, on the 6510 in the C64, IO lines mapped to a memory address).
Maybe I'm just still sore the M68k lost the performance race and I "had to" get a PC.
As you noted, the x86_64 sorted out some of the mess.
Personally, I think a big issue is the whole backwards-compatibility thing. It causes all sorts of nastiness, and a complete overhaul of the architecture is impossible because everything depends on it! (Which is one of the reasons the IA-64 never really became a hit.)
I vote we design our own processors, and write a new kernel to boot. ;)
(IIRC, the 6502 decoded instructions by bitmasks; say bit 7 meant "load" and bit 6 meant "move" or some such thing. So you could trigger combination instructions that'd still execute in 3 cycles but perform the work of two instructions that'd normally take 6. This might have been 6510-only, but I don't think it was.)
I actually had to rewrite some code because of that. I remember the comments in the source code were less than kind towards the engineers responsible. I may even have the listings somewhere.