Generally speaking your argument holds true for addition and subtraction but for multiplication and division there are almost no cases where integer units * (or /) float units are unreasonable, for example "man-hours" (discrete * float) or "pizza slices/minute" or averaging people's heights (centimeters / #raw number) e.g.
It's not that I don't think there's a valid case for this kind of arithmetic, it's just that the compiler doesn't really know what you're trying to accomplish, and in what context the result will be used. All of this is a consequence of a non-perfect world where the compiler can't contextually evaluate what the programmer is doing.
All type systems are just abstractions designed to make it easier to express your intent while minimising mistakes. Storing the result of dividing an integer by a float, or vice-versa, in an integer is totally possible in C, but very likely not the behaviour the programmer intended. Should the compiler just forbid this? I guess what Rust has done is just one possible tradeoff.
For what it's worth, Ada has actually introduced semantics for dealing with arithmetic using units of measurement[1].
