Change control is a more serious issue. Unless you're satisfied going back to the olden days when we had islands of automation, you'll have multiple interfaces connecting the SaaS applications you use. By itself this isn't so awful, assuming you choose SaaS vendors who have built integration points into their architecture.
Where it becomes dodgy is when one of your SaaS vendors decides it's time for an upgrade. If your due diligence was done well, your contracts are airtight, and your vendors are conscientious, they'll let you know in advance. That's very nice, except for the niggling little detail of how you're going to regression-test the upgrade before it goes into production. Few SaaS vendors provide test versions for this purpose in advance (I say "few") because I haven't researched this topic thoroughly enough to say "none" with confidence.
If you are able to regression test, you still won't be in a position to reject the change if you find it breaks something else in your environment.
As there have been more than one known situations where SaaS vendors have changed their APIs without informing their customers in advance, I'd call this one a serious issue.
Then there's root-cause analysis. When something does go wrong with your environment, you're going to have all the usual problems with mutual finger-pointing among your SaaS vendors, because that's what vendors generally do. In SaaS land, "up" doesn't usually mean end-users can function. It means the SaaS vendor's servers are up and the application code running on them reports a heartbeat.
Those of us who have been around a while know this doesn't always mean everything is just fine. Quite the opposite is often true, and troubleshooting a multivendor problem is enough of a challenge when everything is in your own data center.
I haven't even mentioned the challenges you'll face if you have to schedule big batch runs that merge data from multiple vendors (I haven't mentioned it because I've written about it before). A bit of advice here: Don't try. If you have to merge data from multiple SaaS vendors, FTP the data to your own servers and perform the JOIN inside the firewall. Otherwise, network latency will eat your batch run alive.
This is how it looks to me, and telling you this doesn't solve your problem, because just using these insights (assuming you agree with them) merely reinforces the potential for antagonism between you and the team you lead.
So don't present any of this as a reason not to use SaaS vendors. Use it to lay out the engineering challenges the team needs to overcome if it wants to make the SaaS approach usable.
"There's a lot I like about the idea ... here's what we need to overcome to make it work," is a lot more conducive to building the team and your relationship with it than "Here's why I don't like the idea."
And who knows? They just might figure out a way to make it work after all. If they do, please let me know.