IESO, as you say, refers to Internal/External Oscillator Switchover.
It's available (I believe) on all PIC microcontrollers with nanoWatt XLP. This is a significant clue: it has something to do with saving power.
You see, on portable embedded devices, the most precious resource is almost always battery. Not draining the battery too much is something that everyone, from the chip designers, to the hardware designers, to the programmer, has to worry about. As a result, the PIC designers gave the programmer lots of ways to avoid using power if it's not needed.
Most of the power dissipation is in the execution core itself, not the peripherals (I/O pins, USARTs and what have you). So one key thing that a designer needs to be able to do is turn off the execution core (so-called "sleep mode") if you don't need to execute code at that particular moment. There are various ways to wake up the execution core, including POR (power-on reset), the power-up timer (PWRT; this is handy if you just need to go to sleep for a fixed amount of time, like 1ms) or by I/O (e.g. when data arrives on a USART).
However, there is a problem here. The execution core's clock is a quartz crystal (which is external to the microcontroller) connected to a negative feedback circuit. This doesn't require very much power to run, so is ideal for low-power devices, but it does take some time to warm up. This means that there is a delay between the time when the core is woken up and it can run on that clock.
This is where IESO comes in. The PIC has two internal oscillators, a low-frequency one and a high-frequency one (called LFINTOSC and HFINTOSC respectively) which are used for various internal functions. Enabling IESO lets the microcontroller run off one of these internal clocks (you can choose which one until the external oscillator has stabilised. The hardware looks for 1024 clock cycles from the external crystal before switching over to it.
The catch is that these internal clocks are much slower than the external clock. Like, a LOT slower. The external crystal might be running at 20MHz, but LFINTOSC runs at 31kHz at the most. However, this still lets you get useful work done while you're waiting for the main clock to ramp up; if it's a sampling application, it enables you to start an acquisition cycle from the DAC, or if it's communication, it lets you grab the byte which arrived on the USART so it can process another one.
You can pick which internal oscillator will be used with ICRF and INTSRC. Take a look at the data sheet for your microcontroller for the full gory details. In particular, look up "two-speed start-up".
So what's it for? Power managament, basically. It's not really going to be any use to you except under two specific circumstances:
1. You're planning for the device to spend a lot of time in sleep mode to save on power.
2. You need to start doing useful work as soon as possible after it's woken up from sleep mode.
The two examples I gave, where the device will spend a lot of time waiting for the next byte to arrive on the USART, or waiting between acquiring samples from the DAC, are almost perfect use cases for doing this. But it's probably worth noting that it's not necessarily useful in every wake-up scenario.
If you're implementing a pocket calculator, for example, then you're really working at the speed of the user's fingers. It takes so long for the user to press a button that you can probably afford to wait a millisecond for the clock to stabilise. The same goes for a soft power switch.
But you can't afford to wait a millisecond if you're sampling or playing audio at 48kHz, or communicating at 28.8kbaud.
I hope that answers your question.