Wadera well if you're going to update all extensions without testing each update individually, you might as well use the
composer update command without a package list. This will be a lot quicker and more memory efficient.
What your script does appears to be what the
composer update --root-reqs command would do.
What you always want to do is update, test, ship.
When running commands in production, updating is actually shipping, so there's little room for error.
So if you update one extension at a time and verify everything still works, it's easy to identify what went wrong and revert to the previous version if necessary.
But if you update all extensions at once in production and something goes wrong, you'll have a lot more trouble finding the source of the issue and reverting only what's needed.
That's why we recommend updating extensions one by one, AND TESTING the website still works.
Some extensions might also publish specific update steps that you might want to follow during the update. These usually include the
clear:cache command, which you can safely run after every update even if the extension author didn't specify it. Occasionally there might be additional steps.
If you are in a situation where you have a development server and you put your
composer.lock under version control, you can update all at once, verify everything works together, then ship the updated lock file to production. Here updating all packages at once doesn't increase the risks since the commands are not run in production.
If you're going to automate package update, make sure it runs after your nightly database backup and notifies you in case of failure, because if a migration provided by an extension fails for whatever reason, you'll want to know right away to fix/revert your database.