I see what you mean, but I'm not particularly fond of adding that to the Texture Atlas class. Since the topic hasn't come up before (before ~ Starling 2.1, you could not even use the SubTexture workaround), it doesn't seem to be something that's required very often. And my core API principle is still "If in doubt, leave it out".
What I would do in your case: whenever you access a texture, you will have to do that with a static method anyway, probably, e.g.
Game.assets.getTexture. Replace those calls with a custom implementation of yours, e.g.
Game.getTexture that takes care of the scale factor correction. I think that would be a much better fit.