> MariaDB/MySQL + PHP + HTML/CSS and some vanilla JavaScript if necessary. What else is needed?
This is a surprisingly usable stack, I'm tempted to agree.
Personally, I'm on the fence about using server side rendering (which PHP is pretty good at) versus just writing RESTful APIs, because browsers now have fetch API built in which makes consuming them easy (no need for jQuery or necessarily even something like Axios).
Of course, I might still go for a reasonably feature complete framework like Laravel (which handles certain things that you're very likely to get wrong, like auth/encryption or working with mail queues and such), or Slim (which is a nice option for smaller setups, essentially a micro framework; like Lumen used to be).
> I deploy in production using FTP.
This isn't ideal from a performance or reproducibility perspective, but can be workable. A caveat here could be file permissions, depending who is uploading what and how, as well as copying over files that should perhaps be transient (e.g. vendor directory, when you should be using Composer or something like that instead).
Personally I'd go for containers since writing a Dockerfile and shipping/running a container image (even with just Docker or Docker Compose, or Docker Swarm) isn't all that hard. If nothing else, it works wonderfully for getting as many databases up and running as you need, running different versions with different ports in parallel, managing resource limits, configuration and so on.
> My version control is ZIP files in some old hard drive.
This is a very counter cultural stance, that may or may not border on insanity in the eyes of those who want to exaggerate for the sake of an eye catching sentence. Others might joke about file names like code_2022_11_17_release_final(1).tar.gz.backup2 which this workflow might lead to.
Personally, I think that this is just a bad idea, even when working alone. It's good to be able to see what was changed when and have different changesets that you can easily compare, navigate or merge into whatever solution you decide on. Also, it's very nice to be able to revert granular changes, if that's ever necessary.
Try implementing a feature, realize that after changing 34 files you want redo certain parts and need to revert changes in 14 of them, do that with just a few clicks or keystrokes in Git (or other VCS) solution of your choice.
Version control is just a good idea in most software development cases, period. That said, opinions on how to use it and which system to use rightfully differ, as does what to version, whether to use something like Git LFS, whether you need a web UI of some sort or should you work with patches and so on.