Even within just Arabic numbers, it possible for localization systems to add digit separators such as commas, underscores, or periods depending on region.
Sure, str() of an out-of-the-box number in Python won't do localization by default, but Python is a highly dynamic language and I've seen __str__() handlers that do localization, even on things that otherwise act like numbers.
"Simple" string conversion-based "math" rarely is simple in the real world, and ignoring localization and the complexities of Unicode in situations where you are assuming they can't possibly happen is a jungle of mistakes that programmers continue to make every day. The world doesn't run on EBCDIC or ASCII alone anymore, and localization is a thing that matters to a lot of people. The correspondence between code points reported by len(str()) and either input to str() and output to a display device is tenuous at best in anything but the best ASCII circumstances, and handwaving it away is an exercise in your particular bias.
[ETA: And the parent discussion was explicitly about table formatting the output, and that itself specifically is a scenario where you should want to localize the output first and not just rely on str(yourNumber).]