What are pros and cons of Ola’s scripts vs using maintenance plan?

I have written here

Maintenance plans are not bad, but when your environment grows, the limited flexibility and functionality that maintenance plans provide wont be sufficient.

To add more,

• Ola's maintenance solution is widely accepted in the community and large organizations.
• Its open sourced and issues can be raised at github/issues with a likelyhood of getting it fixed very fast.
• Its flexible and scalable (even if you want to deploy it to 100s of servers just use Install-DbaMaintenanceSolution from dbatools.)
• Microsoft took almost a decade to fix Maintenance plan GUI which was buggy itself :-)
• has extensive documentation and FAQs and is constantly updated to accomodate newer sql server versions.
• in preview version, you can even run backups in parallel.
• for index maintenance solution, you can even time the process e.g. if it runs more than X amount of time, abort it.

One of the major advantages of a script based solution is ease of deployment - something that is clearly relevant in your case, as you have 150+ servers. Trying to rollout several maintenance plans (i.e. at minimum 2, one for system databases and one for user databases) across 150 servers would be a nightmare. Maintaining them once in place is just as much of a hassle.

A script based solution is much easier to deploy and maintain over time. Ola's scripts are fairly comprehensive and cover most needs. They represent a great starting point for any organisation to then tweak to match their own unique requirements.

In our case, we have about 40 SQL instances in our DEV environment, and we use modified Ola scripts with the multiple-connections feature of SSMS to be able to rollout changes to the maintenance regime on all 40 instances at one click. Any special cases are handled by our modifications.

I'm not 100% sure of his scripts but custom scripts are way better than maintenance plans. The built in plans will rebuild every index on a table no matter how little fragmentation. If you have Always On it will create a storm of traffic.

Custom scripts you can rebuild anything over 20% or whatever your threshold is. Less indexes rebuilt at a time. Less Always On data to send to secondaries. Faster rebuilding because you are rebuilding less indexes. Shorter maintenance window required.

Last time I used maintenance plans, I had a 300 million row table and Always On would be hours behind whenever index rebuilds kicked off and issues with the transaction log overflowing. Went back to scripts and it all went away.