As an application programmer it wasn't much different from 16-bit real mode. Windows 3.x, OS/2 1.x and 16-bit DOS extenders gave you APIs for manipulating the segments (GDT/LDT/etc). You'd say you'd want to allocate a 64KB segment of memory, it would give you a selector number you could load into your DS or ES register – not fundamentally different from DOS. For an OS programmer perspective it was more complex, of course.
It was true that with 16-bit real mode you could relatively easily acquire >64KB of contiguous memory, in 16-bit protected mode that was more difficult to come by. (Although the OS could allocate you adjacent selector numbers–but I'm not sure if 16-bit Windows / OS/2 / etc actually offered that as an option.)
That said, 16-bit GDTs/LDTs have a relatively sensible logical structure. Their 32-bit equivalents were a bit of a mess due to backward compatibility requirements (the upper bits of the base and limit being stored in separate fields from the lower fields). And the 386, while it has a much richer feature set than the 286, those added features bring a lot of complexity that 286 OS developers didn't need to worry about. Even if you try your hardest (as contemporary OSes such as Linux and 32-bit Windows do) to avoid the 386's more esoteric features (such as hardware task switching and call gates)
I didn't think the segment registers were a big hassle in the 8086 real mode in fact I thought it was fun to do crazy stuff in assembly such as use segment register values as long pointers to large objects (with 16 byte granularity) I think the segment registers would have felt like more of a hassle if I was writing larger programs (e.g. 64k data + 64k code + 64k stack gets you further towards utilizing a 640k address space than it does towards a 16M address space).
I recently discovered
https://en.wikipedia.org/wiki/Zilog_eZ80
and think that 2001 design is close to an ideal 24 bit micro in that both regular and index registers are extended to 24 bits, you have long pointers and all the facilities to work in a 24 bit "problem space" based on an architecture that is reasonable to write compilers for. It would be nice to have an MMU so you could have a real OS, even something with bounds registers would please me, but with many reasonably priced dev boards like
https://www.tindie.com/products/lutherjohnson/makerlisp-ez80...
it is a dream you can live. I don't think anything else comes close, certainly not
https://en.wikipedia.org/wiki/WDC_65C816
where emulating long pointers would have been a terrible hassle and which didn't do anything to address the compiler hostility of the 6502.
---
Now if I wanted the huge register file of the old 360 I'd got to the thoroughly 8-bit AVR-8 where I sometimes have enough registers for your inner loop and interrupt handler variables. I use 24-bit pointers on AVR-8 to build data structures stored in flash for graphics and such and since even 16-bit operations are spelled out, 24 bit is a comfortable stop on the way to larger things.