I really wish people would stop applying the "flat 32-bit" revisionist history to the 386. That wasn't its obvious target, but rather picking up the important "capability" arch features which were seen as the future before unix/c/risc/single supervisor/ideas destroyed the previous 30 years of mainframe/minicomputer OS research in things like security.

So, what this article fails to really clarify is that the segment registers were now basically "selector" indexes into tables with base+length (in either pages or bytes) fields, execution permission controls. And these selectors and the GDT/LDT/IDT/TSS/call gates/task gates/etc were all designed to support OSs with a 4 level permissions hierarchy, user/library/driver/kernel (or similar), passing around access selectors which could do things like enforce the size of data structures, etc. And to support this, they added FS/GS so that all the general purpose registers could have their own permissions masks.

Pause for a moment and consider that again, Pointers (capabilities, aka selectors) can have not only a base address, but a hardware enforced limit, along with a permissions model that means a function like strcpy() would be incapable of writing to any memory that wasn't the target buffer or part of its own scratch space. Languages/os's could have enforced that called functions were unable to write to the callers stack, or even possibly run in their own completely separate stack. And that is just the beginning.

So, here nearly 40 years later the industry is still trying to recover from the mistakes of designing OS's and programming languages around flat memory models and simplistic user/supervisor permissions models. The 386 provided hardware assistance for writing OS's features that to this day aren't common.

ex: see CHERI.