This would have been just as problematic, had it not been for the fact that the buffer is significantly larger and thereby has to be polled less frequently, thereby putting less of a strain on the CPU.
I assume by polling you mean checking the newSS.available() function. This is not to keep from putting "a strain on the CPU". It avoids putting a strain on you, the programmer. 
RS232 communications are typically glacially slow compared to the clock speed of the CPU. It takes a little over a millisecond to receive a byte at 9600 baud. During this time, the 16MHz ATmega on your arduino can process as many as 16,666 instructions!
What interrupt-driven software serial provides (using interrupts and the buffer) is non-blocking serial read capability. With earlier versions of software serial, your program stopped execution (i.e. blocked) until it read a byte. If you did much SoftwareSerial input, your program did pretty much nothing except wait for a byte to arrive. If the program took too much time processing that byte once it got there, it may well miss the next byte.
Instead, newSS uses the interrupt to allow the program to continue executing, at the cost of the program getting briefly interrupted every so often (I haven't looked at the code, but I suspect no more than once per bit-time, or about 0.1ms at 9600 baud). It also needs some buffer space to store its work until the program gets around to consuming the data. In return, you get to program as if your ATmega sprouted another UART, which is not a bad trade if you need another UART.
-j