But let's be honest, the reason it's popular is primarily because it's easy to learn to an "okay" standard, which appeals to the masses
Not necessarily the masses, but for a language for non-programmers was a design goal and places the language in an illustrious tradition.
I think there's a lot of questionable syntax/design decisions in Python
Ah, yes: you hate significant whitespace and consider it eblematic of "poor design decisions". Significant whitespace seems to be a marmite issue: you either love it or hate it. Personally, I think it visually helps reinforce the structure. But, if you don't like it, you're not going to like Python. I think the same divide probably applies to other "typical" aspects which favour clarity and expression and the fact that "everything is an object". No one will criticise Python code for using an additional line of code to make something clearer.
it's comparatively slow (hence why they've tried to address that somewhat in recent versions over the years)
It's more of a tick-tock approach: new features are implemented in Python and optimised later. I seem to remember Python 2.5 was an optimisation release and we had another one after Python 3 became stable. As for "inherently slow", it depends very much what you're doing and what you're comparing it with. Memory allocation for new objects is noticeably slower than compiled languages and loops are known to be slower. For the vast majority of code it is totally unimportant and the benefits of code that it is easier, to read, test and maintain far outweigh the benefits. In addition, PyPy has shown just how fast things can get if you use a JIT and is, in my view, a reason why there is little or no need to encourage static typing.
hence it needs to rely on a lot of functions/libraries/frameworks written in a higher-level language like C to perform many tasks efficiently, then you can't directly credit the Python language for this aspect.
You say that like it's a bad thing! It was a conscious decision to be so pragmatic that has proved both popular and successful to allow libraries written in other languages to be easily embedded in the language. But it actually serves to mitigate another criticism, the "not invented here" syndrome (NIH), that affects many languages. Contrary to the opinion held by many, for example, most mathematicians are not trained programmers and very happy to be able to use Numpy. They could, of course, use Fortran directly in many situations, but there a good reasons why they don't.
As for Django, I've never really liked it, but it has the same advantage as something like WordPress, in that it automates a lot of common tasks, particularly CRUD, albeit at the price of a dreadfully inefficient ORM (a bad idea in itself). But, while it remains popular, it would be a mistake to consider it the only option: more and more work is being done using headless frameworks like FastAPI which work well with frontend frameworks and allow for a different and more flexible approach to the automated creation of GUI controls.
Python is far from perfect, and some of the recent changes including the faster release and shorter support cycles are not welcome. And, of course, Python processes do not scale multiple CPUs as well as other languages, though again, this not really a problem that people encounter everyday. But, before the GIL is dropped entirely, I think more work needs to be done to make the development of asynchronous and synchronous code within the same codebase. This has been brewing since the introduction of generators (actually a major shift) and is still working its way through. I hope, that in a couple of years, people won't really have to care any more but, at the moment, there's no denying it's a considerable overhead.