KNH does the following:
- interactive hooks https://wiki.ubuntu.com/InteractiveUpgradeHooks
- apport notification (depends on apport-kde)
- driver notification (tied to kubuntu-driver-manager
- l10n missing package notification (standalone, starts qapt-installer to do work)
- reboot event notification (standalone, simply reboots)
They are generally all useful (sans apport maybe). Hooks are being used by ubuntu packages, so even if we do not use them, from a platform POV they make sense to support. Driver notification requires a driver KCM which IMO needs a VDG review. L10n is kinda blocked by T2860, offers subpar UX and is fairly meh altogether, so I'd let that task be sorted before deciding whether we want l10n. Reboot is the same platform-useful as hooks (NB: T3137 would make this vastly less useful).
The current code features one KDEd module which supports all those event types through a semi-generic event system. This is however quite possibly no longer the preferred way of handling some of this stuff with systemd being a platform feature we (on a neon level) can rely on. It also has the disadvantage of being more crafty to (auto)test as this pretty much relies on the actual kded being started. Also besides causing some type of notification all these things do not have anything in common. And finally when these things crash they bring kded down (which happened at least once while I was poking the features last week).
Musings on a perhaps simpler hook system https://phabricator.kde.org/T3891#69382 which would be vastly less useful than the platform hooks. It may well be cheaper to implement though.