It's interesting to keep this in historical context, IMO.
You're Intel. The year is somewhere around 1989. Your hardware interface that you export to regular software has gotten complex enough that you want to implement some of it in some kind of software that you can implement at a higher level than just logic. You also maybe want your hardware partners (ie. motherboard and system manufacturers) to be able to change parts for their implementations. Additionally some of this code might eventually end up being hard real time with the possibility of damaging the chip if it doesn't run at the correct window (think power management). You don't have the area budget for rewritable microcode of the size you'd want; this code has to live in DRAM.
You look around at the system software people are running on x86. At the highest quality you've got OS/2, and it goes downhill fast from there. Most end users are running DOS (from several vendors). So you write a higher privilege mode that runs underneath DOS, can actually be pretty close to a tiny RTOS kernel, and document it. But the whole point is to be relatively transparent, and definitely inaccessible to kernel mode, which you don't trust to pull its own pants up after it uses the bathroom.
Then later, when your corporate vendors are asking you to secure the boot chain, it only makes sense that this mode is also cryptographically signed.
And I think this is a more interesting story (and probably closer aligned to the truth). That is, we can get to an anti-user feature that can't be truly owned by the final customers through small steps where each felt like a pro-user customer product decision.