As I was waiting for answers/opinions to pour or trickle in ( thanks, @marquizzo ), I researched a little more on this issue. It turns out, I’m not the first one to notice this behaviour. And it’s not confined to three.js either.
Wikipedia calls this
and it’s being attributed as “the fastest form of texture mapping”. So we’re not talking about a genuine “bug”, but rather about a “known limitation”. My wish for a higher fidelity mapping isn’t original either: Wikipedia goes on to elaborate about
The most promising parts of the latter section seem to be, that:
- doing this in software is about 16 times as expensive as affine texture mapping
- 3D graphics hardware typically supports perspective correct texturing.
Note also in the section on Hardware implementations:
Texture mapping - Wikipedia
Modern graphics processing units (GPUs) provide specialised fixed function units called texture samplers , or texture mapping units , to perform texture mapping, usually with trilinear filtering or better multi-tap anisotropic filtering and hardware for decoding specific formats such as DXTn. As of 2016, texture mapping hardware is ubiquitous as most SOCs contain a suitable GPU.
So this does actually sound quite promising to me. 
The answer to my original question: “can it be done without too much performance penalty?” seems to be a clear Yes, it can!
The more specific question now is:
Can it be unleashed for use in three.js via firmware, driver, configuration switch or else?