The other thing is the ease of replacement versus the cost of abstraction. ECS is a very lightweight service (as are many things like SQS, RDS, etc.) and if you have to migrate to something else that part of it will be the least of your worries, but unless it’s highly likely that you’re going to switch cloud providers you are likely to have many years of not needing to spend time running an internal cloud. Similarly, unless you anticipate switching on a hard, near deadline it’s likely that the effort of porting later will be less than the time you’ll save in the years before the mandate comes.
That’s a room full of people who can be working on the things your users actually ask for rather than treading water, especially because one big challenge for an internal PaaS is that you have to build a ton of services to even be an option: if a project needs one feature your PaaS doesn’t offer, they’re going into AWS and you get none of their business. I suspect they hit that trap of just not having enough resources to stay competitive with what their users needed.
EKS really isn't much harder to build out than ECS - but it doesn't set you up to be much more cloud agnostic.
So I guess the tie is larger than it seems at first sight.