Every engine being sold that I've run across has had some form of rigidbody physics.
We considered incorporating one, but at the end of the day it just added complexity to the apis. We’ve never had great experiences with built-in physics engines. And for 2D games, we found that the geometry apis we provide to determine collision were good enough.
I understand that you think it should be a standard/default feature. I really do get that. But we didn’t want to incorporate something half-assed just to check a checkbox on a feature list.
To prove my point.
Take any of the engines you’ve evaluated and try to get a sprite to run up a diagonal ramp. It should be a piece of cake with a built in physics engine. Right?
Another thing to try. Have a platform that moves up and down. And try to get your player sprite to stay in sync with the platform’s movement, until they jump. Again, this should be trivial to do.
Personally, I'm glad DRGT doesn't have a full blown built-in physics engine, this is a detail that I'm interested in implementing a solution for instead of attempting to tailor a "one size fits all" unity-ish solution to work for my desired implementation. Once you start digging under the hood of DRGT you'll find it has many of the utilities (geometry/LERP functions, etc) you need to get there and you're usually just an abstraction or two away from a working implementation.
I don't think there is a "right answer" here, it all comes down to personal preference.