Again, absolute nonsense. Microkernels were designed for entirely different reasons than microservices. There are hard technical reasons for and against them, and most, if not all, microkernel OSes are still distributed in a rather monolithic model, not piecewise.
Where did I mention microservices? How does the fact current microkernel OSes are being distributed using a monolithic model imply my point is nonsense?
A real microkernel OS with stable interfaces would mean its developers do not want control of all the kernel-like servers, and allow even basic users to easily install and use many alternative user servers, as opposed to Linux kernel services sanctioned and controlled by the Linux distribution kernel maintainers.
Those things are completely orthogonal. A microkernel can arbitrarily restrict what user servers are viable (for example just the ones it ships with), just like a monolithic kernel can arbitrarily restrict what loadable kernel modules are viable (for example just the ones it ships with).
A compiled microkernel can restrict, I agree. But if you want to restrict, why would you do a microkernel. It's much easier to justify with a monolith.
One big point of making a microkernel as opposed to making a monolith is that you want to give other developers more freedom to develop, distribute, fix bugs on their own time schedule, while keeping compatibility with new kernels easily. In other words, not wanting to control what and when they do, and what users run on the kernel.
Monolithic kernel like Linux, with its constant stream of little changes in interfaces, creates problems for developers of modules, and this leads to selection - those who keep up and satisfy the kernel requirements get in, those that don't keep up or do not satisfy requirements, can't get in, and are degraded to developing against some old kernel version. This is a kind of control.
