A second stop bit in the transmitter makes the communication more resistant to interruptions, allowing the receiver to detect a true byte start faster than with one stop bit.
When you have a continuous stream of bytes and you turn on the receiver mid-stream, chances are that you get a byte from its middle, taking actual data as a start bit and confusing start/stop bits as part of the data. Of course this means that you'll get garbage for a while. Errors will accumulate until the receiver finally gets the real start bit for a word start and the stream stabilizes. When that happens depends on the data itself; it's more likely to happen after bytes that end in ones, like 0x01, 0x03, 0x07, 0x0f, 0x1f or such., because they have fewer zeros to be taken as start bits.
When you have two stop bits, statistically you'll get to that point faster than with one stop bit (provided that all bytes are transmitted without any pause or delay between them, which would act as effective additional stop bits). This was specially useful in old hardware like teletypes with very low baud rates and very noisy lines, especially if you don't have an underlying protocol (with checksums, retransmissions and such).
It's still a good measure to use two stop bits (in the transmitter) if you've got any of the forementioned conditions.
Of course you've asked about the receiver side. I don't think it's very useful to use two-stop bits, but it could help to detect framing errors as well depending on the implementation (whether the word is rejected or accepted when an error is found).