For a moment, let's talk in general terms, not about how Python chose to do it.

Most languages have scopes. Things may exist in your scope, so you can access them. Or they may exist but in some other scope not visible to you where you currently are. Symbol tables track what is in a scope.

A variable is a name associated with a storage location. The location could be a stack, heap, register, or something way more abstract as long as it behaves as a "place" you can store a value into and read from.

When a variable is created, a name is defined and some storage is arranged for. But that name is also added to a scope. (If it weren't, it would have a name, but nobody could see it.)

There's no reason, once the variable has been added to one scope, that it can't be added to another scope. That is what "import" statements do in a lot of languages.

Python has apparently chosen a very different approach for imports, which is to create a new variable. This isn't necessarily wrong or right, it's just not something I had ever seen a language do before.

they likely are referring to how import mechanisms in other languages operate outside the scope of imperative execution, like Perl's "use" statement, or in the way that a compiled language like Java handles imports. It is exactly the vast confusion that Perl's "use" caused me, even after I used Perl in a professional setting for almost ten years, that allowed Python's "first class object" approach to imports to be one of the most liberating breaths of fresh air I've ever had in my programming career. Of course, imports being imperatively executed causes the nasty problem of import dependency cycles in code but it doesn't even bother me.

It's not specific to compiled languages. An interpreter has access to the symbol table while interpreting your code in the same way that a compiler has access to it while compiling it.