You see this across technologies all the time. Engineers overvalue simplicity, which leads them to pick the lightweight framework (e.g. Flask vs Django, Sinatra vs Rails). The project grows in complexity and they end up having to reinvent the more full featured framework.
This has only ever made sense when Django is not being used as a web framework. A person may want to use just the templating engine in a script, or the ORM in another framework. I could see how installing all of Django in those scenarios to use some small portion of it could be considered bloat.
It is imaginable that Django the web framework could be made up of sub-packages for the admin, templates, ORM, etc, but it was created at a time where Python package managers didn't really exist. Being a single package was (and probably still is) easier.
Bloat, like beauty, is often in the eyes of the beholder. Always ask: "By what measure?" or "Compared to what?"
Django is large, encompassing, and opinionated, so much "bigger" than "micro" web frameworks like Flask. But it's comparable in scope and cohesion to other "batteries-included" web frameworks such as Ruby on Rails or Laravel for PHP. As always, YMMV.
I assume they are talking about how Django contains lots of stuff by default, whereas many other "frameworks" include much less. E.g. Flask doesn't come with a database layer, or session management, or pretty much anything.
Now if that constitutes "bloat" or "fully-featured so I don't need to coble lots of libraries together" is a matter of taste and use case.
There are devs out there who obsess over making sure their builds/programs/whatever are small in terms of bytes so they don't like anything that imports more than they need.
Django has everything. It is "batteries included." Well, many devs find many of those batteries to be useless, a.k.a bloat.