As a Django dev, I don't think its anywhere as easy to deploy Django as PHP.
In terms of initial setup of an application than doesn't use anything but the standard library in either language I would completely agree with you.
Edit: Composer, not Artisan as dependency manager in PHP.
Granted, Composer is slow, but it works so well, mainly when package developers tag and release packages properly though. What issues do you have with it?
"composer parallel install plugin" is what it calls itself - it downloads all the repositories before composer gets to the install step and then composer just loads everything from cache - super fast!
It takes much more manual work to set everything correctly than running a python application.
They weren't saying it was hard but that it is not as easy as PHP. PHP is one level up from a static site for most beginners, you can simply drag and drop a file on many shared web hosts and get going. That is the attraction.
If you're writing something moderately complex then you're very likely to be running it on a virtual instance (maybe more than one) on AWS/Digital Ocean/etc, and if that's the case then you'll go much faster if you have a testable, reproducible build process that your development team can tear down and build back up easily. That is much more complicated than FTP'ing a few scripts to a server and importing a SQL script with PHPMyAdmin, but at the same time, as soon as your service hits a few thousand users with hundreds of them accessing it concurrently, your PHP script FTP'd to a shared server probably isn't going to work very well.
Learning new things is not a reason to avoid moving forwards. If anything, it's why I got in to web dev in the first place. New things are what make it interesting. I don't learn all of them, and I don't switch tools very often, but sometimes something comes along that makes life better. Reproducible builds with Ansible/Puppet/Chef/etc is one of those things.
It's better to insist on simplicity at every level, whether you're building "simple one-person web apps" or "complex large-team" ones. In fact simplicity at every level would be even more beneficial in the latter case.
So I find this "dead easy deploy is only beneficial for small apps" dichotomy false.
If a deploy fails and a client is panicking because their app isn't available, the last thing you want is a team of stressed developers trying to work out which files they need to revert.
"Simple" doesn't mean "easy".
Who said it's has to be either one or the other?
The "manual process of copying files to a server" can be done simply by a person for a small scale project, and it also can be automated any way one likes -- e.g. to "automatic copy files to a server when code is merged in to a repo".
"Copy a file to a directory and the server just works and shows it" doesn't imply manual ftp uploading or manual editing of any kind -- it's just so flexible and easy that can it work that way too.
And if anything breaks, it's still simpler to find out what went wrong -- as opposed to some convoluted server deployment process with more moving parts.