While what you wrote is correct, it's not actually the problem being described in the posted link. The problem in the posted link is just as relevant if the alpha value was "01" for "you pretty much can't see it but it's meaningfully there", and has to do with image filtering artifacts as opposed to purely data representation.
But it's specifically a problem with PNG because the spec explicitly allows encoders to substitute their own RGB values for any transparent pixel. Most other formats are expected to store the values you give them without modification.
No, the problem discussed in the article can occur with any image format (that supports alpha) and occurs later in the pipeline so it really doesn't matter how the texture was stored on disc. Or even whether it was stored - this could happen with procedurally generated textures.
The article discussed one possible workaround, which was to specify RGB values for the fully transparent pixels in the artwork. If the PNG tool you're using substitutes its own RGB values in those transparent pixels, as allowed by the spec, the workaround doesn't work. That's why PNG in particular is a problem.
If you follow the recommendation at the end to use premultiplied alpha for all computations, this becomes a moot point.
