I am not 100% sure of what I am about to say, but most likely it is correct.
Messages are dispatched from source (S) and travel to the destination (D). Hooks (Hx) are logically located between those 2 points. Hooks can be used to process the travelling message for whatever purpose (for example, traffic filtering). With this in mind, we can visualize a working Windows system as follows:
When a hook is done with processing the message it passes it on to the next one, using CallNextHookEx, until no hooks are left. By not calling the next hook, you ensure that the message never reaches the destination (hence the warning from Microsoft).
The solution you propose would not work, because it would simply disrupt any message exchange between password manager and the user application. You can imagine a hook that does not forward the message as a firewall drop rule, all messages are discarded.
Another issue is that you can't always have access to the memory space of the process where the message is going. As a standalone passwors manager program you can't set hooks within other processes, such as firefox for example, while a keylogger can. Because of this you can't even set a hook in the first place.