There are lots of simple physics-related simulations that are unstable at low- or variable-frequency (spring compression, rotational fields with correcting factors to compensate for discrete integrations, etc.). Using the semi-fixed time-step also helps with the underlying implementation, as we know the simulation will not need to try to cope with certain degenerate cases, which helps with collision detections, computing swept surfaces and volumes, etc.
That might have little impact on small games that don't actually need any of these features, but it's usually good practice to prioritise stability of the simulation under reasonable assumptions when implementing a physics engine. Therefore there's no real reason not to do it, even if you don't need it. It might feel a bit over-cautious, but it ensures some form of consistency.
Also, it is NOT realistic to expect a physics simulation (or any mathematical computation, for that matter) to be deterministic across multiple platforms. While a physics simulation can be made deterministic on a given platform, it relies on the low-level math hardware for that platform. While a recent desktop CPU will provide fast vectorised maths with high precision, a mobile chip will certainly offer much less precision. This difference will cause inconsistencies. When using native code, even a compiler switch (fast math, etc.) can modify the behaviour of math/physics computations.
When it comes to math/physics and computers, determinism is a very tricky requirement and should be considered a major technical risk for any application. If a game relies on deterministic physics, you're likely to need specific libraries for every category of platform, as a recent i7 and an old iPad2 have little in common in terms of electronics. Obviously, this gets easier if you target a limited set of platforms only ; which is quite hard to do if you have "mobiles" in mind.