There are a couple of different things happening in that question.
Is it due to the limit of binary system to express floating-point numbers?
Loss of precision isn't due to the use of binary, it is due to keeping the storage size constant. It also happens if you work with, say, 8-digit decimal numbers, also if you do it with pen and paper. Eventually you may need to round. But sometimes you don't, and indeed even with floating point numbers on a computer, some computations are exact.
we have integers with million digits length
We do, and we can use two of them to hold very precise rational numbers. Then loss of precision does not occur as long as your calculation stays within ℚ (which is already an annoying restriction), but as the numerator and denominator get larger, computations slow down, and eventually space may run out.
Floating point numbers stay the same size as they are manipulated, computations stay fast, and there is no risk of running out of space, but the price for that is intermediary rounding.
0.1 + 0.2 is not equal to 0.3
Actually it's worse than that: 0.1 is already not 0.1, in binary the number 1/10 suffers the same problem that 1/3 does in decimal, representing it exactly would take infinite digits.
The literal 0.1 converted to a double precision number is already rounded, to a double that encodes the value 0.1000000000000000055511151231257827021181583404541015625. Close, but not exact. Since usually floating point numbers are not printed exactly, this is usually hidden, but it's happening.
0.2 rounds to 0.200000000000000011102230246251565404236316680908203125, and summing them gives 0.3000000000000000444089209850062616169452667236328125. On the other hand, 0.3 rounds down to 0.299999999999999988897769753748434595763683319091796875.