The conversation is about portability, and the observation is that the code you're talking about still assumes an address is a scalar variable, which effectively means it assumes IPv4 addressing. That's all.
I'm not super thrilled to debate the performance merits of optimizing 16-byte strings vs. 4-byte integers. I use whatever is most convenient. It's slightly easier to convert a charstar to a u_int32_t, but it's much easier to index a u_int32_t.
The conversation is about compatibility, not portability. ie: what is the best way to store ipv4 addresses so that they are compatible with ipv6 addresses when you need to start supporting those.
At any rate we are talking about two different things.
if you have the ipv6 address 1234:0000:5678:0000:0000:9212... you can write it a number of different ways, using the :: abbreviation for the various runs of zeros. ipv4 really doesn't have that pit fall in the string representation of its addresses.
So, if you store it as a string one way and then latter when you get input that has the same address written another way you are going to have problems if you don't normalize. Since we are talking about storing in a database, as the parent to this chain was you would likely want to normalize to the most compact representation to save space in your database. The precise type semantics of your language of choice are irrelevant.
I'm not super thrilled to debate the performance merits of optimizing 16-byte strings vs. 4-byte integers. I use whatever is most convenient. It's slightly easier to convert a charstar to a u_int32_t, but it's much easier to index a u_int32_t.