While this article does a good job of showing the PS cmdlet for backup, I think it obscures the complexity of backup. This method works ok when you treat all the DBs on the server the same, but I've been in large shops for yrs backing up servers with thousands of DBs going to many locations at once. They've also got different requirements for striping, tuning settings, retention, cert backups and password mgmt, etc. There's much more to backing up SQL than simply producing a loop with a simple statement.
And even if all that other stuff went away, I think a PS solution disregards the complexity of deployment. With PS you'd have to deploy a script to each server because the PS agent task is a piece of crap. So now you've got to put a folder out in the same location on every box, so you've got to find a location that all boxes have in common where someone won't delete your scripts. A lot of shops won't let you deploy anything at all to C: so you've got to find a mutual drive, which may be harder than it sounds. And there are differences between versions of PS that are going to throw things off as well as some boxes may not even have PS on every server.
Most of the stuff I've mentioned is easier and better managed in tsql because those settings would likely live there, and your code is less likely to be deleted out of SQL itself.
So while I accept your premise that under this limited simple circumstance, PS is easier, SQL backup as an enterprise process is very complex and has lots of exceptions, settings, and processes involved with it. And it needs to be managed at an enterprise level in a way that's easy for the DBA team to report on and make changes to. And having settings anywhere but in SQL will make that very hard when you're dealing with thousands of boxes and even tens of thousands of DBs.
There I tried to keep that as short as I could.