Not really. L4 family (the post-Liedtke world) and Minix3 both have MM out of the kernel.
Firstly, as the MM daemon runs on its own process and is well-separated from other code, it is far easier to audit, debug and so on. Its interface is also entirely explicit. There's value in modular programming. It's far more reasonable to expect quality from such a MM daemon than the mess in a random monolith kernel.
Secondly, in seL4, physical pages are capabilities. There might be more than one MM daemon, owning separate sets of capabilities to physical pages. Security-critical memory might be managed by a MM daemon your vulnerable process has no capability to talk to.
Just my two cents.
I am not very good at theory of Operating Systems but since Memory Management is separated from kernel it would have been difficult for a memory bug to impact other subsystems.
Another argument is modularity which would have allowed better testing hence lesser chances of bugs.
While it's true that vendor drivers living in kernel space is horrible for security... that's somewhat offtopic here. This particular bug is in the memory management system, which is one of those things that kind of has to be in the kernel. A microkernel architecture seemingly would not have helped in this particular case.