It makes perfect sense for a PNG encoder to set the RGB value to zero when the alpha value is zero because it allows it to compress the image better without changing the result. How were they supposed to know you would be using a RGBA image for something other than RGBA.

The problem with that is that they assume you'll only ever display the RGBA data with nearest-neighbor filtering / square pixels. Pixels aren't squares, but points, so it's not a valid assumption -- even on a web-page, the image might be rescaled, printed, etc.

Filling transparency with black is basically just using pre-multiplied alpha -- if they do that, they should also pre-multiply partially transparent areas. Then, programs displaying the PNG can compose it using pre-multiplied alpha blending, and everything is fine and dandy (any filter will work).

The Photoshop exporter seems to produce unpredictable RGB values in transparent areas though, so it's impossible to ever filter it with anything but nearest-neighbor (unless you modify the image first to correct for the exporter's mistakes)...

An ideal exporter would leave these as options for the user to choose

Rather than thinking: "How were they supposed to know you would be using a RGBA image for something other than RGBA"

I think: "How dare they assume that my alpha value represents transparency!" - There are a million things you might want to use an alpha channel for.

Sure, have a tick box in the .png encoder settings to zero out the RGB for transparent texels, but don't turn it on by default, and don't do destructive actions without consent.

Given a PNG texture that is completely transparent with no color parts acting as the destination, and a red color {1.0,0.0,0.0,1.0} acting as the source in the glBlendFunc(GL_SRC_ALPHA, GL_ONE) equation:

Final color = (source color*source factor)+(destination color*destination factor)

= ({1.0,0.0,0.0,1.0}*1.0) + ({?,?,?,0.0}*{1.0,1.0,1.0,1.0})

I have no idea what OpenGL uses as the RGB component for a fully transparent texture in order to complete the equation.

As already mentioned by others, if a pixel has an alpha component it necessarily has RGB components. But the error runs deeper: PNG compositing makes sense only with a fully opaque background, not with a fully transparent background. The bKGD chunk provides a reference colour that a transparent image is going to be composited over if not composited over some other opaque image.
This is completely different from pretending the transparent pixels are opaque: the red paint in the original question would be composited over the bKGD colour (unaffected by a whole image of fully transparent pixels), not over garbage RGB data that is harmless by design because it can only be non-drawn with zero opacity, never "resurrected" by pretending it's not transparent.

The PNG specification is unambiguous:

10.7 Background color

The background color given by bKGD will typically be used to fill unused screen space around the image, as
well as any transparent pixels within the image. (Thus, bKGD is valid and useful even when the image does
not use transparency.) If no bKGD chunk is present, the viewer will need to make its own decision about a
suitable background color.

Viewers that have a specific background against which to present the image (such as Web browsers) should
ignore the bKGD chunk, in effect overriding bKGD with their preferred background color or background
image.

The background color given by bKGD is not to be considered transparent, even if it happens to match the
color given by tRNS (or, in the case of an indexed-color image, refers to a palette index that is marked as
transparent by tRNS). Otherwise one would have to imagine something “behind the background” to composite
against. The background color is either used as background or ignored; it is not an intermediate layer
between the PNG image and some other background.

Indeed, it will be common that bKGDand tRNS specify the same color, since then a decoder that does not implement
transparency processing will give the intended display, at least when no partially-transparent pixels
are present.

In practical terms, what's wrong is putting meaningful RGB data but alpha=0 in all pixels of the original image: it should have either fully opaque alpha (255 or 65535 depending on bit depth) or RGB format (Color Type 2 rather than 6).