Thanks for the helpful replies and not just closing the topic this time.
The current implementation does make more sense if the whisper feature itself is considered beta/testing and might change significantly in the near future. The impression I got was that the feature itself was more or less finalized and only the underlying protocol was planned to change.
Certainly if the feature itself is considered to be in testing and likely to be changed or replaced then I can understand not wanting developers to build upon it. My case is a bit different though, as a developer of a chat client; my goal isn’t to build new functionality based on existing features, but just to ensure that all those features are as accessible as possible to users. Whether they’re in beta or not, I want to ensure that they’re available, so that users aren’t missing messages and feeling left out of the neat stuff everyone else is getting.
I still think it’d be helpful for third-party developers if this and other future features were, at least optionally, exposed via the standard IRC interface. (In fact there are some existing features I’d love to see added to IRC, like mapping stream title to TOPIC messages, broadcaster/mod/staff/etc to user MODEs, etc.) It would make development of chat clients, bots, and other tools simpler. (Currently my script makes several API calls for various events, which is a lot of overhead. Some of them can be removed now thanks to IRCv3 tags, or at least they can once HexChat allows those to be read by scripts…)
For example, it should be possible to implement whispers as sender NOTICE receiver :message; since existing NOTICEs only (as far as I know) come from jtv and twitchnotify, there shouldn’t be any collision with those (and a message tag, like the message ID tag already in use, can help distinguish them). Or they could be implemented as sender PRIVMSG receiver :message (how private messaging usually works on IRC) or even sender PRIVMSG channel :receiver: message (as was previously done with some jtv messages, tying the message to a channel, which would be more helpful for bots).
(Also, if it were possible to send them by sending W receiver :message instead of only PRIVMSG #jtv :/w receiver message, most clients would be able to send them without any modification, since most will send commands to the server if they don’t understand them themselves.)
Other future features such as offline delivery could be implemented in similar ways. I feel like this could be an appropriate compromise: provide whatever API/protocol is most appropriate, and also provide a CAP for IRC clients to request these new features. That way there’s no worry about constraining those features based on IRC limitations (and with CAP you’re free to use non-standard protocol extensions, since a client must explicitly request them), and if IRC isn’t suitable for the feature, it can be provided in a more limited form or not at all.
A lot of people who use IRC like the simplicity and flexibility - plain text messages, control over windowing and formatting (many use it in a text-only terminal), scripting capability, etc. Those users might not necessarily want things like pop-out/persistent chat windows; they’d rather choose on their own whether to move things to separate windows and how to manage them. On the flip side, some people use it because the web chat isn’t accessible*. Those users typically want the same features and experience they’d get with the existing chat, so the more a developer can provide them, the better.
(* I personally use IRC because I hate Flash, and dislike the amount of padding and large “send” button the web chat has. I watch Twitch on my Android tablet, and IRC lets me also use the chat on my PC while the tablet plays in fullscreen. Friends of mine have similar setups because their computers are too old to handle Flash video streaming, or because they want to idle in a lot of chat channels, for which IRC clients provide a more convenient interface than popout chat windows. Some of them use scripts to alert them to potentially interesting messages or even read them out loud.)
Anyway, thanks for offering some more helpful answers, even if I was a bit stubborn about it. 
