Do I need the Multiservo-Board?

TL;DR: Yes, you do!

The Multiservo option for the SMuFF seems a bit redundant you may think, because: 

Well, those are all fair and good arguments. Although, there're always two sides to a medal.

Let me shed some light on those arguments.

The first versions didn't use the Multiservo board...

This is true and closely related to the second argument. The very first servo that got added to the project was the Wiper servo and it's (only) purpose was to clean the nozzle after swapping the filament. This explains why the Wiper has index 0 in the firmware, although it seems "less important" than the others. After this the Lid servo and lastly, the Cutter servo have been added.

Without a servo controller, each servo uses a dedicated I/O pin on the MCU to generate the PWM signal, although the pins in question are mostly fake PWM pins. Which, in this case, relates to the second argument: 

Every MCU can generate PWM signals...

Which is true but more complex than it looks at first glance.
Firstly, not all pins on a MCU are able to generate a true, stable PWM signal but only those designed to, which is explained in the MCUs datasheet. To be able to release this "superpower", you have to pick one of those I/O pins for your PCB layout. You also need a spare hardware timer, which is internally associated to that pin. No matter what MCU you use, I/O pins and timers never seem to be enough for your current project (especially if the board layout wasn't designed for your project in first place).

There are certain ways to overcome this limitation: Use one general purpose timer and a bit of software to get as many PWM pins/signals as needed.
Sounds great, but in reality it isn't that great in some situations. See, timer interrupts used by software always depend on the current state the MCU is in and eventually what the ISRs (Interrupt Service Routines - the piece of code that handles stuff as interrupts are triggered) are doing. Under certain circumstances, these interrupts may take longer than expected and hence, other interrupts may occur later than sooner, which eventually will mess up the timing. A messed up timing will result in an inaccurate pulse width, which causes jitter on the PWM. This might not be relevant on LEDs but on servos it's pretty easy to spot as they seem to go mayhem.

A servos position depends on an accurate timing and if that's not within the specified range, it'll either move less or more degrees than one has intended. As the servo signal is periodical (i.e. every 20 ms) this inaccuracy will repeat over and over again and hence cause that jitter. Not only that this is very annoying if your sitting next to it, it can - depending on the application - cause unwanted behavior, e.g. the Lid servo when the servo horn moves off the lever. 

Since neither of the usual suspects, such as the supplied servo voltage nor shielding the PWM signal did result in any significant change, I've spent days debugging and tracing down the issue. I eventually tried to optimize the firmware code, in order to get rid of this annoyance. This included measuring not only the PWM signal itself with an oscilloscope but also measuring the time certain code-fragment needed for execution (i.e. raise an I/O pin when it starts, pull it back down when it ends). A very tedious and time consuming task.

Conclusion to my findings...

To really get rid of this issue, I needed a better, hardware oriented solution, that doesn't involve soldering wires to the controller board/MCU, that's widely available and reproducible by others.
Luckily, I was not the first and only one running into this problem and some clever designers made an IC, that addresses this problem. This IC is the PCA9685 which initially was launched as a 16-Channel, 12 bit LED Driver but since it's equipped with an I2C interface and internal hardware timers to generate the according PWM signals, it can be used for more than only driving LEDs. 

Adafruit designed a PCB around it, which enables an Arduino (or similar) to control up to 16 servos (and, as I've later found out, it's also being used for the DC-Motor controller used for the Spool-Rewinder).
Fun fact: I had such a Adafruit Servo controller laying around and I even had already implemented the code in the firmware in an earlier release, because I was experimenting with some other option, which never really took off.

So, I reused this board and code for the servos (Wiper, Lid and Cutter) and low and behold it solved the servo problems instantly.

It makes the project more expensive/complicated

Yes, it does add a bit to the overall cost of this project but it doesn't make it more complicated. It's the contrary, it makes your live easier. For one, as it's not bound to the electronics housing, you can move the board into a "better position" related to the servo positions. For the other, it's easier to find an issue in case it's related to the servos. Lastly, since such a board supports either 8 (i.e. FeatherWing Servo) or 16 servos, it's pretty much future proof.   

No other MMU / 3D printer uses it...

Hey, that's not my fault!

To sum it up...

That's the reason why you want one. If you're convinced now, here're the instructions on how to wire it all up.