This is nearly my exact experience at work. I work on an internal tools team, so my users are other engineers at the company. Product teams have Product Managers and seem to put in a lot of effort into their OKRs, but for the internal tools team, we're in some limbo: still forced to write OKRs, but no parts of the process that are actually useful. We might have an OKR to upgrade Jenkins before an EOL date, but no introspection about whether the company at large would be better served by GitLab CI (as an example). Management only cares that we have defined KPIs like "Days remaining until Jenkins EOL date" and that they are improving. I still try to have the difficult conversations, but it's a constant battle with management as improving developer happiness by allowing them to use a better system isn't easily demonstrated on a dashboard.
Also, like you said, teams write their OKRs in a vacuum without coordinating with other teams. So, one engineering team might have an OKR to fix some memory issue affecting their Jenkins pipelines, but they didn't communicate that with the internal tools team that operates Jenkins. It then became a struggle between the two managers, one saying "We need to fix this Jenkins issue or we'll fail our OKRs commitment" and the other saying "We already committed to different OKRs this quarter, we can't take on new work." The engineers are stuck between this battle trying to help each other in secret without management hearing about it.
A lot of the lack of coordination devolves into cost center arbitrage as well. Often intentional.
I once worked at a shop that outsourced their datacenter to such a low cost bidder, that simple RAID disk replacements would be delayed for weeks and in a couple cases caused complete loss of a RAID array due to cascading drive failures.
Of course the datacenter guy got to point to his OKR for reducing operating costs. Meanwhile the "Big Data" team using their services was saddled with their losing days worth of highly paid engineers time as we chased tickets, dealt with data recovery, etc.
I'm now sat in the "final customer" internal seat and seeing it from the outside. IT brought us their new years plan to decommission some stuff I use, when I prodded a bit, they admitted was basically a cost allocation problem.
They were pushing the responsibility onto users like me, because they weren't good at allocating costs. No argument that it was more efficient or a good use of their customers time/resources. Simply that they hadn't gotten around to implementing metering so why not just stop offering the service entirely...
Also, like you said, teams write their OKRs in a vacuum without coordinating with other teams. So, one engineering team might have an OKR to fix some memory issue affecting their Jenkins pipelines, but they didn't communicate that with the internal tools team that operates Jenkins. It then became a struggle between the two managers, one saying "We need to fix this Jenkins issue or we'll fail our OKRs commitment" and the other saying "We already committed to different OKRs this quarter, we can't take on new work." The engineers are stuck between this battle trying to help each other in secret without management hearing about it.