I have seen it, over and over again, in relatively small orgs (under 500 devs) where the wrong kind of people are handed the job of platform lead. Project after project people don't want to use. The platform jobs in those places were handled by technical skill, but it was attached to disinterest of how others work. So even when they were sent in the general direction of a useful problem to solve, things rarely pan out, because they don't like to talk to their users. Therefore they write the tools they would want to use and are interesting to build instead.

Empathy for other developers, trying to have a mental model of what annoys them about work, and a general product centric mindset are the real requirements, but few people that decide how to staff the team k ow how to measure those skills. And besides, when people have them, they are often sent to talk to the actual customer, not internal customers.

I worked at a big company where the actual platform teams were serving the internal users ok, but then there was some middle layer of org-specific platforms that strangled entire projects. Eg some kind of custom database someone invented.

My efforts were often focused on cutting stuff like that out and using the company platforms directly, which was hard because there were reasons people had middle layers. The company platforms weren't bad per se, but they were in-house and hard to find expertise on.