Just speculating here, but it might have been a product decision to encourage writing code for protected mode. It's also possible it was a combination of technical difficulties and product priorities.
The CPU is put into protected mode by setting the PE bit in MSW using the LMSW or LOADALL instructions. Clearing the PE bit has no effect using either of those instructions, thus it is not possible to switch back to real mode. The fact that LOADALL allows undocumented behaviours like "unreal mode" (by loading values into descriptor caches to access memory outside of 1MB) and even allows you to put the CPU into an unusable state by loading nonsensical values, but disallows clearing the PE bit makes it likely it was a deliberate product decision. OTOH, LOADALL is undocumented, so maybe there really was a technical problem.
Just like switching from real to protected mode, going back to real mode is a carefully choreographed dance that needs to make sure all memory accesses go to defined memory locations (especially instruction fetches). The documentation has a strange passage that says "After executing LMSW instruction to set PE, the 80286 must immediately execute an intra-segment JMP instruction to clear the instruction queue of instructions decoded in real address mode" hinting that there is more to it than just setting or clearing a bit somewhere. It probably wasn't completely trivial to implement (not very hard either, but it definitely would have had a cost if you're counting transistors or microcode ops. The 80286 had ~134,000 transistors, and using a couple 100 transistors to implement an unnecessary feature would probably have meant dropping other, deemed more important features). Since they didn't anticipate a need for it, maybe they weren't willing to pay the "silicon tax".
There are still ways to get back to real mode by resetting the CPU without restarting the computer. On the PC, this could be done by putting a magical value into a special memory location to prevent the BIOS from reinitializing the computer after a reset, and then causing a reset through the i8042 keyboard controller which would externally reset the CPU, or by generating a triple fault (faulting in a fault handler, usually by invalidating the IDTR and causing an interrupt).
Using the triple fault is usually much faster. Going through the keyboard controller can take almost a millisecond, the triple fault only a couple hundred microseconds. Even with the triple fault, the reset circuitry is still external, but it doesn't have to be processed by the very slow i8042 (some PCs of the time "short-circuited" the reset bit in the 8042 port to directly reset the CPU without going through the i8042, in that case, there's no noticeable difference).
The reasons to switch back to real mode are all due to technical debt, you wouldn't need it in a clean system that's designed for protected mode from the ground up. In reality, people kept writing software for real mode and were unwilling (or unable) to quickly port stuff like device drivers to protected mode, and the 2 don't mix. Maybe Intel was trying to "encourage" people to port their drivers to protected mode by making it necessary, but as we know, this didn't work out.
Intel didn't make that mistake again, and the 80386 fixed the glitch both by allowing mode switches in all directions, and by adding a virtual 8086 mode that was essentially a protected mode that looked like real mode to the application.