This is a big deal imo. There are many tutorials out there on fuzzing servers, but anything that abstracts away the source code changes necessary to fuzz servers is a great thing. Essentially this is taking what those tutorials do and making it so you don't have to adapt those tutorials to the particular software you are dealing with. If it is easier to fuzz software, more fuzzing will be done leading to more bugs being discovered and fixed.

At The Irssi Project, fuzzing has been very effective in helping to discover bugs. Fuzzing can turn up bugs that aren't otherwise found or that are unreproducible through typical use of the program. See https://irssi.org/security/.

Of course Irssi is a client, not a server. IRC servers often have protections against frequent connections and messages, which can result in fuzzers getting kicked. So this new development in TCP server fuzzing outlined in the article is a great improvement, but there are going to be cases where the code of the server will have to be modified moreso than just swapping out the main function (which I know the author never claims to not be the case).

Or, things like DNS servers, where request sent to it, can also induce another request from that server to an upstream DNS server - and it's be good to provide fuzzy data to both those cases (as client and as upstream server).

Very interesting, I didn't think of using AFL for a network level, and I have not heard of Honggfuzz until today.

I thought about doing this earlier and my thought was that this could have been done with something like Scapy or at a basic level hping3.