Microkernels are usually considered more secure not just from the theoretical point of view. Usually their capabilities are more restricted then those of a "general purpose" monolithic kernels and thus contain less bugs purely because their codebase is smaller. Conversely, the more code you run with high privileges, the better are your chances of disaster.
From the theoretical point of view, there are several key points why a microkernel is inherently more secure (provided it is implemented correctly):
separation of the drivers from the kernel (and each other) - a failing/malicious audio/network driver can't crash or even silently modify the kernel (or another driver or user application). One of important cornerstones of this separation is implementation of IPC by message passing instead of e.g. shared memory, since it allows the kernel to sanitize the data transferred. The same holds for "regular" user processes obviously. It is also one of the biggest performance penalties when compared to monolithic kernels.
Drivers being separate processes can run in a different protection ring than the microkernel and applications that do not require any hardware access at all. This has to be supported by the hardware, of course.
Leaner codebase allows formal verification of some microkernels including the end-to-end correctness of seL4 (remerkable achievement, if you ask me). Thus a well written specification may result in expected results only. This makes the addendum about implementation above redundant.
Apart from that, microkernels are also safer: a failing driver can be restarted without the rest of the system being affected (this obviously mandates applications using that driver being a bit resilient against driver failures). That means that a failing display driver in a passenger aircraft not only can't bring down the whole aircraft control system, it doesn't even cause the need for a full reboot taking several seconds (which you don't have when you are landing, taking off or flying in rough weather). Classical example can be INTEGRITY (178B) - note, that it (like many similar kernels/systems) lacks things like dynamical memory allocation, which is just a kind of comfort that you have to live without if you want to put constraints like hard real-time execution on your system.