(Apologies for the greatly-delayed reply: I didn't notice your comment for ages.)
I'm not sure I understand your argument. It seems to go like this: "Years ago some people said one of Python's design choices was terrible, and it turned out to be fine. So if you think a language's design choice is terrible, then I have no respect for your opinion."
I don't see how that makes any sense. (I mean, obviously you are welcome not to respect my opinions! But I don't understand the reason you give.) Some possible language design choices are terrible, no? To take some extreme examples, we can probably agree that the choices made by INTERCAL, Brainfuck and Malbolge are (deliberately) terrible. So, you surely can't actually think that thinking a design decision is game-endingly bad, as such, means having un-respect-worthy opinions.
Maybe what you actually mean is: Deciding not even to try using a language because of one design feature you find terrible is evidence of incompetence, and therefore if I do that then my opinions shouldn't be respected. But, again, surely that's obviously wrong; I don't need to try programming in INTERCAL to know that it's not going to be a good use of my time (unless as a joke).
My best guess (which of course could be wrong, and I welcome corrections) is that you mean something like this: "It should be obvious that this design decision in Nim is no weirder or worse or more unreasonable than Python's decision to make whitespace significant. Lots of people thought that was obviously unacceptable, and with hindsight we can see that they were silly. Since this feature of Nim is no more unreasonable than that feature of Python, you're being silly too."
But I think it's incorrect to say that this design decision in Nim is no worse than significant whitespace in Python. Or to say that I've no more reason to think it bad than people exposed to Python early in its existence. (I also think those people weren't necessarily silly if they thought significant whitespace was a terrible idea, though I think they were wrong to think that. I would not discount someone's opinions on programming language design merely because I found they'd thought Python's significant whitespace was a bad idea when they first encountered it.)
Nim's variable-name rules have the following consequences.
1. Standard tooling will do the wrong thing with Nim names. If you want to search your Nim codebase using grep, or index its identifiers using ctags, or find the next instance of a given identifier in the file you're editing with your favourite text editor, then you're out of luck. (Unless your favourite text editor happens to have added special-case support for Nim. Some editors do have some Nim support; e.g., there are packages for Vim and Emacs that do this. But there are some very basic things they don't do -- e.g., I would like the * key in Vim or C-s in Emacs to be able to search for identifiers in my code, and it doesn't look to me as if this is something the available packages provide.) Consider also searching on the internet; do you want to bet on Google and other search engines learning to interpret things that might be Nim identifiers according to Nim's rules?
2. There are some (admittedly rare) distinctions that there's simply no way to make in Nim identifiers. As an example, someone upthread mentioned "inform" versus "in form". I wouldn't expect this sort of thing to matter often, but as a matter of principle it seems to me extremely poor taste to have a set of identifiers that simply can't represent arbitrary short English phrases unambiguously. (It's a bit like in old versions of C, where compilers and linkers weren't required to be able to distinguish anything more than the first 6 characters of each identifier, case-insensitively. You can always work around it, but having such a restriction there at all is a sign that someone hasn't thought things through.)
These are genuine limitations imposed by Nim's identifier-name rules. There are obvious easy-to-foresee ways in which they would lead to inconvenience and trouble when using Nim. Of course, it might turn out that the advantages (in, e.g., letting you use external libraries with a variety of stylistic conventions, while keeping a single style for your own code) outweigh the disadvantages, in which case I'll have made a mistake in not wanting to pursue Nim further for this reason. I'm comfortable with that; I have a finite amount of time and have to choose somehow what things are worth spending the time to learn well, and inevitably sometimes those decisions won't be optimal.
So far as I can see, there is (and was in 1992) no objection to semantically-significant whitespace in Python that is (or was) as cogent as this. There was "it's weird and unfamiliar" (which, in fact, I think can be a perfectly adequate reason not to put time into something; again, time and effort are limited and one has to prioritize somehow), and "it makes copying and pasting more error-prone sometimes" (which I think was never a strong objection for anyone using anything smarter than Notepad for editing, because you need to be able to fix up indentation whether you have block delimiters or not), and that's about it.
So, to me right now, it doesn't look as if the situations are parallel. Of course I might be wrong! Maybe back in 1992 there were objections to Python's whitespace rules that were just as apparently-cogent as the objections above to Nim's identifier-name rules are now, and I've just forgotten what they were or how plausible they seemed. But I don't think so.
(Pedantic note: Python doesn't use indentation for scoping. It uses indentation to delineate block structure, and some languages that are not Python use block structure for scoping. Python's blocks do not in general create their own scopes.)