> unzip this file in that folder

it's more like "copy these files via ftp to this host" (p.s. that also includes your config.php with plain text passwords of course)

The problem with the "copy these files" approach, even more than dealing with FTP, is that the upgrade process winds up being "copy these files, but be careful not to overwrite any changes you made". Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself.

I got fed up with this a few years ago and started building http://bitmash.io (yes, shameless plug) which does some fancy filesystem manipulation to swap out the application's files during upgrades while otherwise looking like a perfectly ordinary PHP hosting provider. While I'm proud of this solution it still seems rather silly to have to jump through these sorts of hoops to handle deploys.

>> Applications like WordPress or Piwik come with a self-updater, but then you wind up with having to fiddle with the permissions to let the application overwrite itself

Tell me about it! It took me an entire day to figure out how to configure a WordPress install in order to allow it to self-update (without ftp). To do it by only granting owner and/or group write permissions, you have to figure out that you need to modify wp-config.php to define the "FS_METHOD" constant with the value "direct". Without this, WordPress code tries to be super clever with its umask settings, which only makes things worse.

It quite literally took an entire day to set up WordPress to self update. It's easy if you chmod 0777 nuke the entire install, but extremely complicated to set up with acceptable filesystem permissions. WordPress is designed to be sloppily dropped in a webroot, not to be installed by intermediate users who care about security. Well, as "secure" as WordPress can be. And to be honest, the most secure WordPress installation would be incapable of self-updating, as you're granting the web user write access to the entire installation - not just for updates, but for any vulnerability.

Use two users, and wp-cli. I've been doing this for years now. Php runs as a less privileged user, without​ write permission. If they want to install plugins, they need to enter the FTP name and password of the site dir owner user. Since the FTP connection is localhost, no passwords go over the wire in plaintext. Next, you install wp-cli, and add a real system cron job to 'wp core update', and 'wp plugins update' every hour. You can also do things like transient cleaning once a month, or whatever else, and running the WordPress fake cron.

You can then disable wp cron, which saves network resources.

Personally I find ftp as an unacceptable protocol for this purpose. Doesn't matter that it's localhost. It just goes to show WordPress is truly aimed at the lowest common denominator.

The fact that doing a filesystem-level end run around is simpler and more reliable boggles my mind. When I started experimenting with it I thought "this will never work, there's all sorts of things that can go wrong" but I eventually wound up migrating all of my PHP-based applications (WordPress, Piwik, and PMWiki) to it because it was so much easier to work with (even with maintaining the control software) than doing it the standard way.

Well, yeah. Point being that if I'm used to working with .doc and .xls files there's next to zero new skills I have to learn and nothing that really pulls me out of my comfort zone. I just have to install a text editor ("like Word, but for .php files") and an FTP client ("type this magic string to set it up, then it's just a funny looking file browser") and I'm off to the races.

A lot of things happened in php world,since you last checked, which is apparently ~ 5 years back. for starters go read about Magento 2 codebase and its code organization and deployment strategy. Whether you do FTP based file deployment or sophisticated CI/CD build, it all depends on developer not programming language you are using.