It is absolutely business-as-usual to decouple physics (and related ops like ray-based picking) from display values. Two common examples (I welcome any others as comments):
- OpenGL uses the float range 0.0->1.0 in x and y, thus abstracting display code from resolution (and thus, pixels).
- Box2D is also built for such decoupling.
But having said that, it's not always necessary, which is why you see some people simply using 1:1 ratios. OpenGL and Box2D are libraries (write-once-use-many-times), so they need to be applicable in a range of circumstances. As such, they wisely do not tie the user into implementation specifics of this sort, since your choice may be totally different from that of another user of the library.
There is nothing to say that an engine may not do perfectly well, if for example the physics are specifically built to work at 1:1 scaling -- or any other fixed scaling, for that matter. You typically still use floating point to deal with fractional values in your physics. (Another alternative is a custom-built fixed-point implementation, if you are running on older hardware -- but that is still a non-integer.)
(Disclaimer: In the particular case of Box2D, Erin Catto has stated that his engine is optimal at a 10:1, physics units to display units ratio. This is based on floating point precision limitations which meant that some optimal ranges had to be chosen for the physics ops to be less "granular" while still supporting relatively high velocities. You can choose your own ratio however. It just provides a smoother experience at 10:1 or higher.)
For 2D games, I normally first consider level size in metres or feet, then consider viewport size such that you know what percentage of the level you want to see at a default (1.0) level of zoom, then decide on the supported screen resolution, and then finally use that inform your decision of what your sprites' pixel dimensions need to be.
(Thanks @JoshPetrie, @NicolBolas, @e-MEE for getting us this far on the OP's question.)