You may get in touch with Protected Mode (PM) in the following cases:
You will not get into contact with PM related stuff very often. Modern 32 bit OSses give you up to 4GB for code and data as a huge, big piece. This should be enough for practically all cases. Because you do not need to care about how the memory is organized by the OS and all hardware-specific transactions are done by PM OS services you can enjoy the simplifications of PM without the need of knowing how it works.
Under 16 bit OSses this is a bit different. You may reach the limit of 64KB per segment quite rapidly. Coding may be easier if you know how new blocks of memory are organized by the OS. It may also help in finding the reason for instabilities.
If you are writing drivers for a PM OS you will often be confronted with the different Privilege Levels (PL) and the restrictions and possibilities related with them. You may also have to work with Real Mode, 16 bit PM, 32 bit PM and V86 specialities. In PL 0, you can do hardware accesses denied in other PLs. But you have to be careful with the way PL 0 code runs in the OS. It is quite often possible that critical parts are running without task switching or protection mechanisms. One error can stop the whole OS!
Unless you are not writing a sort of memory manager you can concentrate on communication between code running in different PLs (e.g. transferring control from PL 0 to PL 3 can only be done indirectly), PL 0 specific operations and the core layout of the OS without bothering too much about the rest.
However, writing a PM memory manager or task scheduler is a much harder and more complex thing...
This sounds strange: What has a standard 8086 Real Mode DOS program to do with Protected Mode (PM)?
The answer is: Although you may not use PM at all in your programs they may run in PM - DOS boxes in PM OSses are using V86 mode, an extension of PM.
You may not feel the difference considering memory addressing, but your code runs in Privilege Level (PL) 3 - not in PL 0 like in clean, Real Mode DOS. If EMM 386 is used, V86 Mode will also be activated. You are not allowed to execute several instructions reserved for the OS, I/O port accesses may be virtualized and behave in an other way as you expect - or not at all (just take a look at the W95 DOS box, you can crash the OS by manipulating the Timer hardware). Things like automatic hardware detection, tweaking hardware directly and using undocumented functions can - not in all cases - crash your program. It may be useful to use these methods only where it is really a standard: Use BIOS VGA modes like VESA or 13h for fast screen accesses instead of Mode X, try to keep sound routines as generic as possible instead of tweaking the DMA controller and the soundcard. Other things should be done only through OS functions if possible.
Do not forget: Reloading segment registers in V86 and PM is much slower than in Real Mode.
If you are using DPMI you are predestined for using and setting descriptors. You may have to use 16 bit segments for DOS stuff while your code executes in 32 bit. And you have to start with Real Mode segments before entering PM selector based code and data access. If you are using the graphic RAM directly or writing your own DMA routines you will have to create descriptors mapping your data fields to the physical addresses in RAM.
Your code is normally restricted to PL 3 with all its disadvantages and the descriptors and calls are done through OS functions. But you have to know what these functions do - most DPMI functions only execute PL 0 functions because you cannot set descriptors in PL 3. It seems to me that most DPMI serves do not contain any checking of the parameters you send to them - they are just setting them, ignoring all protection guidelines. Nothing will prevent you from locking the system by setting wrong values.
Switching between Real Mode parts and PM parts of your program is also a typical DPMI situation. Thus you should have an idea how the different switches work.
For those who do not know: Flat Real Mode is done by starting in Real Mode DOS, switching to 32 bit Protected Mode, loading the segment registers with selectors which point to descriptors set to a segment size of 4GB and switching back to Real Mode while keeping the segment register values set in Protected Mode. One may expect what you are back in the standard Real Mode, but - due to the fact that the 386 does not reset the segment limits while switching back to Real Mode - you have full 32 bit access to the whole memory while using 16 bit code.
This sounds great (it is), but there is one big problem: You must start in Real Mode rather than in V86. Most people today are using PM OSses, and the few still having DOS are often using EMM386. In both cases you cannot switch to PM because the CPU is already in it, your code runs at PL 3 and the switch will not work.
If you want that more than one or two people out of 100 are able to start the program without problems you should forget this method and use another, like DPMI instead.