Hi Sam,
Since I'm more or less a lurker, I can't really answer this question on behalf of the LWIP team. But I thought I'd bring up a couple of points.
If you clone the lwip git repository, you'll notice the first commit was in 2002. In that time period, if I remember correctly, strict aliasing compiler optimizations were bleeding edge. People were still figuring out what this new "restrict" keyword was and how to use it. Compilers weren't heavily optimized around strict aliasing at that time.
Also, formal definitions of strict aliasing aside, 'void' is not a type. Therefore one would not intuitively expect that casting a 'void*' to a particular type would be an aliasing violation, since you really only have one type.
IMO, this has always been a somewhat gray area in the C standard (or at least not well understood and agreed upon), and that's why compilers have options to disable strict aliasing, so you can choose the option that eliminates the ambiguity.
Finally, I would argue that issues like these illustrate the need for good QA and unit tests. (No one is going to deploy a networking stack without a fair amount of testing and integration work, so this almost goes without saying.)
Regards,
Mike