That paper was written a few years after Python was released, and before 2.0 was a thing. The article says it's already being used that way in industry, and reasons why vs just doing native code from the start (faster dev time and whatnot). The way module loading and the whole standard library works facilitates native extension.

His stated goals for Python were generally:

• clean code for the interpreter
• clean syntax to make intent clear
• easy to learn and use

They go so far as to reject changes that significantly increase performance if it complicates the code. Why? The simplest explanation is that if you need the speed, building your own native extension is the way to go. That was the way I've been told to use Python: write in Python, and if it's not fast enough, rewrite the slow parts in C/C++.

LuaJIT is an example of the opposite approach, where the interpreter is designed to be fast enough that you generally don't need to use native extensions, and they prioritize performance over features, unlike Python. As a result, community contributions are very limited, and many people stick with the official runtime.

Python wouldn't be very successful without native extensions, so I think it's absolutely fair to say it was an early design decision.