Just pointing out that the 5 second boot time is better than a regular VPS. Which (combined with per second billing) makes this good for batch/cron oriented serverless functionality. But is too slow for "function as a service" type serverless where the end user is waiting for it to fire in a browser.
It would depend on "how things are wired together". Now, it's great if they are "wired together" in such a way that one need not give it any thought. But whether we're talking EC2 instances or containers, at some point one has to think about it, e.g. two instances talking to each other, one being on the East Coast USA and the other in the Midwest, or West Coast, vs. their both being in the same datacenter. That's at the extremes, for sure, but maybe even intra-dc clustering has to be considered explicitly for certain applications? Maybe not?
Even with those it was still worth it. A couple people maintaining the CI is nothing if you can make the build of the 350 other developers twice as fast.
Also it's not like hosted CI is without maintenance, if you want it to not be totally sluggish, you have to use some quite complex scripts and caching strategies that need to be maintained.
IMHO, nobody should care / worry about the underlying orchestration. The industry is moving toward the public service model, and all these management problem is solved by the cloud platform, not app developers. Check out hyper.sh, that's what container service would be.
