decimals cause huge problems for computers. How do you represent 0.6 as a floating point? In the long run, the correct solution is for everything to be binary.
In the long run, trinary gives you the best radix-economy, being closest to e: https://en.wikipedia.org/wiki/Radix_economy
In base-N, you can accurately write any fraction of (1/y) provided that y can be expressed using the same prime-factors found in N.
For example, 10 has the prime factors of 2 and 5, leading to the requirement that y=(2^a × 5^b) .
This means base-10 can accurately represent (1/80), because 80 = (2^4 × 5^1). In base-2, you're limited to stuff in the form (2^a).
Finally, the, uh, infinity-of-integers that matches (2^a) is always going to be "smaller" than the infinity which can be matched by (2^a × 5^b), since the latter "contains" the former when b=0.
In this fashion, primes p seem "better" as they increase, because for a given size limits on k and n, you get more 'numbers' per unit space on the real line. Composite numbers are 'even better', but there are a lot of pains in the ass with composite numbers, stemming from Z/nZ not being a field if n not prime.
Ultimately, though, your internal representation is binary, using anything not two produces other inefficiency. That's why IEEE 754 BCD is not base-10 but base-1000 (since 2^10 = 1024 which is the closest a power of two gets to a power of 10, for bit-wise representation efficiency). We don't have bi-quinary computers.
In fact, I think it exemplifies the upper bound for the number of digits you'd need for "related fractions". For example, we know "one eighth" is expressible in decimal as 0.125. Even if you pick a really big N value, N * (1/8) should never need more than three digits to the right of the decimal point.
But there are two approaches that we can use.
The first is to point out that in real life it is more common to encounter small numbers than big ones. So if you choose a probability distribution for what denominators you expect in practice, and sum up the values of all of the exactly represented numbers, you can get to a fixed probability of even division. And it won't be zero.
Unfortunately your choice of the relative probability of having a 2 in the denominator versus a 3 is extremely arbitrary. So while the approach makes sense, the numbers you get really will be made up. (Though no matter how you make them up, your general statement is guaranteed correct.)
The second approach is to just look at how the count of exactly representable numbers below N scales with both N and your set of primes. This has been studied. The exact counts are a mess, but if you have a set S of prime divisors of size k, then the count is (1+o(1)) * 1/k! * [product over p in S of (log(N)/log(p)].
The upshot is that for large N, more prime factors always wins. And for specific prime factors, you just look at the ratio of logs.
For instance with this approach we can say that log(3)/log(5) = 1.46497352071793... times as many denominators are exactly representable in base 12 as in base 10. (The log(2) factors cancel out.) Therefore base 12 is better.
Of course the second approach says that base 6 is as good as base 12, and it is smaller, so why not use it? Well, the reason why we keep on winding up with base 12 in practical situations is that divisibility by 4 comes up a lot. It isn't just exactly representable that matters, efficiency matters.
It is easier for the computer to adapt to us, rather than vice versa. And over time things get easier and easier for the computer, while staying the same for us. Which is why over time we wind up interacting with computers in ways that are more and more adapted to us rather than them.
We already have acceptably good algorithms to convert to/from different representations, and roundoff errors are generally acceptable. (If they weren't, we wouldn't default to using floating point for most things.) Where precision matters, we have reasonably efficient implementations of exact integer arithmetic and exact fraction arithmetic. The performance hit from using these is less than the hit from using a high level language like Python versus a low-level language like C.
The main challenge is getting programmers to use the right representation for the purpose that they are using it for. Which is mostly challenging exactly because floating point works so well in practice that it is easy not to learn what its limitations are.
In physics it is uncommon to have exact measurements for much of anything except integers. In physics, measurement error is usually a bigger issue than roundoff errors from floating point, so the non-existence of an exact floating point representation of the stated measurement is a non-issue.
In the real world, most cases that I'm aware of where we need exact base 10 calculations have to do with dealing with money in a single currency. You would be amazed how often square roots don't come up in this context!
Fractions show up as soon as you start doing currency conversions. (In fact the Euclidean algorithm for finding the GCD is believed to have been first developed by merchants for exactly this problem.) They are easy to add to a programming language, but you'd only use them in contexts (like finance) where square roots make no sense.
If you want to go beyond fractions to add square roots and so on, you can do algebraic numbers. This is a fairly specialized mathematical need, but Mathematica has done it perfectly well for decades.
For arbitrary real numbers, we're sort of stuck. We can come up with representations that can cover any real number that we can talk about. But we can't take 2 arbitrary representations of a real number and in finite time decide whether or not they are actually the same number. That said, Mathematica again solves this problem "well enough" for most practical purposes. See http://mathworld.wolfram.com/Ferguson-ForcadeAlgorithm.html for more.
This is a complex topic, with ongoing research across multiple fields of study.
That said, floating point is a "good enough" default for a surprisingly wide variety of situations.
It's just that top to bottom very few people are willing to trade the loss of speed for the increase in accuracy (not that decimal is great either, you still run into plenty of repeating fractions)