Here are my thoughts - apologies for long comment.
Take the worse case of a servo needing, say, a 2.5ms pulse every 20ms.....it has to be every 20ms otherwise the servo goes 'floppy' - no torque.
The pulse length (2.5ms) is critical - any +/- deviation makes it jitter. ie flicking between 2.4ms and 2.6ms = jitter.
Why would anything be so in-exact as to cause this jitter? Well - if there is any 'software' involved in controlling the length of the pulse then that software can be interrupted via hardware interrupts (ie the uart needs attention, the I2C bus needs attention, the ADC converter needs attention etc etc). The more of these opportunities you introduce (by asking the same board to do lots of other things) increases the likelihood that this will happen.
Hardware PWM is great - as everything is happening in hardware and cannot be influenced by all the other things your program is doing and any interrupts they may cause. Its rock solid. But you need one timer for each servo - and that's the problem. You've probably only got 1, 2 or 3 timers available. So great for a two wheeled robot, say.
Software PWM is cheap but inaccurate. It uses one, ore more, timers to not only control the length of the pulse but also to control which output pin the pulse is sent to. The pulse length, and change of pin, is performed via interrupts. So if your board is handling all sorts of interrupts (I2C, UART, etc as above) then it gets in-exact. For example: if it is using timer interrupts to say when the '2.5ms' pulse has finished (so it can turn off the output pin) then this can be delayed slightly if the CPU is having to deal with other outstanding interrupts. This is partly a problem with the AVR chip architecture - some other chips allow you to prioritize the interrupts which in our case would mean that we could make sure the servo pulse interrupt is given highest priority - but on AVR you can't do this. However: software PWM is not a waste of time - if your servo are modified for continuous rotation, rather than angular position, then this momentary change in speed is not normally an issue - either due to momentum or coz you are using encoders to cope with all of the other differences (like the diameter of your wheels is not 100% identical).
Glitches/twitching - this ONLY happens if software is involved in getting the PWM signal to the pin - due to the problem of other interrupts happening concurrently as mentioned above. Of course if your board is only doing software PWM from one timer then there won't be any other interrupts. However: with WebbotLib it is sort of assumed that you also need a system clock for measuring time - and so there is always an interrupt for this. The only way for PWM which involves any software to be exact is if it disables ALL interrupts whilst generating the pulse. The problem here is it can mean killing off everything else whilst generating a single 2.5ms pulse for a single servo. Have 8 servos and it means 8*2.5=20ms ie kill the machine for 20ms - oh and we need to do it every 20ms - so the whole machine is dead. That ain't good if the same board is talking to other sensors.
So the only TRUE way of producing glitch free PWM is to either use hardware PWM (for a few servos); or to use some sort of software assisted PWM where the number of other 'non servo related' interrupts is kept to a minimum - ie a slave board or other extra hardware. The only other interrupts the slave board would need to re-act to is the comms from the host to say what speed/position to use for a given servo. Although this is still an interrupt - it is only one interrupt - and you don't tend to need to change positions very frequently so it doesn't happen very often in the scheme of things. That's why there are so many slave servo controller boards around.
Hybrid solutions. The 74HC238 solution in WebbotLib is a kinda compromise. It uses a single hardware PWM timer for generating the pulses (with all of its benefits) but then controls the 74HC238 via software to direct the 'pulse' to the appropriate output. So, as 'klims' says there is 'an overhead' but this is more in the pin switching than the pulse length. So it should be jitter free.
74HC238 vs 74595? Well since they both involve external hardware then they will both no doubt require software to be involved to help control that hardware. So they are both in the Hybrid category. Not "heard complaints about the SCC-32/74595" - well thats probably because it is a slave board. My comment about 'overhead' with the 74HC238 is when you have it connected to your master, Axon say, board along with everything else.
Since you are talking of creating a slave board then I would have thought that either route would work. The 74HC238 is dirt cheap (don't know about 74595) so you could knock it out on a breadboard for a few $.
