Plus anything running on your system can be subverted by anybody attacking your system.
That is the major limitation to 'file hashing' HDIS type things. The only very effective way to run them is by taking the system offline and hashing from a alternative OS like a Live CD or something. And whats more you'll have to do all your installs, upgrades, and patches while the system is off the network and perform hashing before and after every upgrade.
Huge pain and very expensive to do this sort of thing 'right'. There is very little business justification for that level of expense.
Although I expect one of the arguments from OSSEC using folks would be that hopefully OSSEC module running on the machine would be able to relay information back to the central server before it's subverted by the attacker.
(on a side note)
I expect that HDIS can be wielded effectively when combined with a strong MAC policy applied via SELinux. Since it's very difficult to contain exploited user processes on any sort of *nix (and expecially) Linux systems. The attack surface for local user accounts is just too massive for DAC + "depend on good programming" to be effective. That way you can use your HIDS to monitor your services and make sure that they are not subverted... Of course... one kernel-level exploit and everything is toast anyways.
Ideally MAC + HDIS could be effective against kernel-level exploits if you combine it together with TPM (which is hopefully tamper-proof from the software side of things). That way you can do something like establish a 'chain of trust' from trusted module to system firmware to bootloader to kernel to initrd to userland which each part of the system's job is to validate the next item in a boot up.
But that is STILL limited to protecting you against attackers retaining control of your system through a reboot. Your still screwed if you have a exploit that is exploitable on the fly and the attacker goes through pains to make sure that they always operate from system memory and does not modify the file system binaries or configuration files in any meaningful way. To protect against that you'll need some way to monitor and validate code operating from RAM!
All in all it's completely space-cadet thinking that people would ever get something like that running in a cost-effective way.
(on a side side note)
NDIS, of course, is very useful and can be done in a cost-effective manner, but nowadays it's not as useful as it once was. Long gone are the days when somebody will crack your server and install a IRC bot or server on it or something like that to control your systems. Instead nowadays they will subvert a existing service and relay commands to the root kit mixed in and disguised as legitimate traffic.
I would think that it would be very difficult for any NDIS to be able to cope with that.