Counterpoint: the absence of logging, monitoring, host-based IDS, and all the system engineering tools you have on Linux is a big negative for security.
You can compile in these metric collection facilities into the unikernel if you need them. The whole point of unikernel is to allow you to mix and match only the things you need.
You can log and send metrics from your app over a network (which you should probably be doing instead of writing on disk), monitor a VM, IDS makes no sense when you don't have logins and such. And the tools are rarely installed on "cattle" anyway.
I'm not sure anyone would advocate the application to monitor itself. Many companies have entire teams of people that have to deal with keeping machines up and they get paid big bucks to do so.
As for the IDS question/statement - can you explain in more detail? Are you talking about file integrity checks or? Unikernels don't have the concept of users or shells or remote login or many of the things that an IDS would actually be looking at.
If it was something such as an attacker overwriting a shared library and you want to monitor or ensure that can't happen both of those operations are feasible in unikernels.
File integrity checks are from the 1990ies. There are various domain-specific HIDS, most of them closed source, that observe the runtime behavior of applications.
Also a lot of hardware and VM management software that perform remote administration functions, e.g. asset tracking, reacting to low batteries on UPSes, monitoring network health...
It's absurd to think that a whole OS worth of code should be jammed into the application or the unikernel. That's what traditional kernels are for.