Performance is not bad. It's clear they aren't using Nintendo's TCP stack, as it was notoriously terrible on the Wii.
By networking, I am assuming you mean console stack... which I had experience with myself, and yeah... not great. But even more, their web services (more than 10 years ago at this point, hopefully better now) were so, so bad.
The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.
Young me thought they were silly for being so "behind the times". Older me respects it more.
https://en-americas-support.nintendo.com/app/answers/detail/... (Point 4 under "On a PC or smart device")
Beyond that the servers were also badly implemented and from what I understand they had to call in a third party company to install TCP PEPs[1] in front of the servers to get acceptable performance.
The Wii has ample compute power and memory to max out a Fast Ethernet (100Mbps) port, but due to the design decisions it was barely able to push 1Mbps in real life. This was becoming a problem as system updates were getting larger and the built-in "channel" games were moving beyond NES and SNES ports to actual third party indie titles that sometimes got rather large.
[1] https://en.wikipedia.org/wiki/Performance-enhancing_proxy
Besides running on a weaker CPU, IOS can access (for exclusive use) some of the main system memory, but it was usually about 12-16MB to not starve the actual games running on the main CPU (https://wiibrew.org/wiki/Memory_map), which can help explain why everything except for the actual games was so slow.
Originally, code running on the main PPC CPU could not access directly most of the IO related hardware at all (only GPU/display output and wired controllers - the bluetooth stack was also on IOS AFAIK, but the Wiimote drivers themselves were userspace), so even the Linux ports had to "proxy" some hardware access through the IOS, but later after reverse-engineering the full boot process, people were able to create a replacement IOS that could enable full access through a special register: https://wiibrew.org/wiki/MINI, enabling full-speed Linux ports, and since that functionality is about a decade old now, I would guess that the NetBSD port also takes advantage of that.
You'd think they'd just admit that and outsource their network-related needs to a company that specializes in that sort of thing.
Innovating on games with multiplayer and then putting in a wifi chip that gives a ping of like 100ms at best seems like orthogonal goals.
This actually reminds me of two very interesting bugs which used together basically make it so that you can play WFC games (basically just Mario Kart Wii, nowadays) as simple as changing the DNS settings on your Wii
1. Firstly, as long as you set a particular field in the certificate, it just is completely happy with an invalid cert. (This was fixed by the NWC library by the time it was released In Korea, notably, although this bug was present in DWC for a long while.
(Aside:
I actually suspect that this bug was present in the RVL SDK (used by games and such on the PPC), but also is caused by the same cause as the signing/Trucha bug[1]. While the latter is a IOS specific exploit, it wouldn't surprise me if the same code was used in both this and DWC (the networking library). Given that Mario Kart Wii has an associated IOS version of IOS36[2], but DWC code isn't part of IOS, my hunch is that they used either the same or similar validation logic OR both bugs were squashed a part of some security related cleanup.
I haven't actually gone through the reverse engineering effort to confirm this yet, but given that this doesn't work on the Korean version of MKW, which notably uses a later version of IOS and other libraries, my hunch is that those bugs are one in the same. The fix timing at least seems interesting to me. Anyway side note over.)
2. The networking library also has an RCE caused by a buffer overrun, basically from the first message it has a length that's unchecked and the DWC library blindly memcpys data from the packet. This is kinda why it's important to have some sort of patchset that fixes these bugs (because the operating system and libraries ship with the game and you can't update those except for in memory).
The culmination of this is all you have to do is
1. Change your DNS settings on your unmodified Wii to point to a specified DNS server.
2. Start Mario Kart Wii (probably, although some other games work too), open up WFC
So that the game...
3. Does a DNS lookup for the WFC server which intentionally links to a 3rd party server
4. Passes validation of a bad cert which intentionally sets one of the fields to a null value in order to make the Wii accept it
5. Receives a message that contains an exploit which patches the game in memory to fix the known RCEs and setup URLs to resolve to different domains instead of using the old WFC ones among other things (such as cheat reporting that is all client-side based, etc)
all so you can play Wii games (probably Mario Kart Wii) online 11 years after WFC shut down for good :)