A NNTP service could definitely still work, but it would have to be a lot more locked down. I really hate that the alternative is web forums which are always stuck with a small fraction of the functionality of any good news reader and get bogged down easily if they get popular and never have a good search feature.
NNTP is just the right abstraction to wrap any discussion-based thing. It would be nice to have just nntp://news.ycombinator.com, nntp://reddit.com and so on instead of bunch of incompatible APIs actually. It's like beautiful Perl's TIE [1] where you wrap an object in it and it exposed as regular scalar, array, hash or filehandle instead of 'an object' with it's own methods users need to learn to use it.
I think Gmane 2.0, if it ever will be born, would have a mechanism of plugins, that allow easy wrapping any web-forum in it, by writing a little template describing the layout of pages like 'this is topic, this is message body' and so on. And the crawler to use the plugins, of course.
A version of NNTP where groups were automatically moderated and strong controls were in place to weed out spammers and trolls could work. The moderation would have to be baked into the core of the protocol and not some weird half measure bolted onto the side however. Once a community is large enough you either moderate it or you get another /b/.
NNTP is a very nice, simple protocol to implement, both server and client-side.
Well, except for the mess that is RFC 822. At least NNTP decided to go 8-bit safe eons ago, so you just have to shove everything in UTF-8 and you can screw RFC 2047 in the face.
* Handling attachments can be difficult (particularly the inability to safely add binary data)
* The display name/address is both painful in terms of syntax.
* CFWS in general (you can tell who's written an email client by their reaction to the letters CFWS)
* Header fields in general have way too lenient handling, so there's no way to, e.g., guarantee non-ASCII handling (RFC 2047 needs to be handled differently in the Subject: header than from the From: header, and the Content-Type: header does something else entirely).
* Mandatory line-length limits, which means you need to be able to insert line breaks in however you encode custom header values
* No way to get attachments without the body or vice versa
* All metadata needs to be shoved into a header (see above about i18n, line length, and CFWS)
