My experience with platform teams is, once they are formed, they suck up the best people. Doing k8s/technical stuff.
People that should have been working on building products.
People that should have been working on building products.
If you don't find it interesting to build products with whatever tool is most adequate (excel some times) maybe you should not work at a company building products. At least you should understand that you are part of the support team not the main guy.
And yes, moving to GitHub from Jenkins is maybe objectively a good choice. But if it stalls product development for 6 months, is that objectively-objectively a smart move? It could of course be, but it requires more situational awareness than "is this tool better".
This is normally where you see the product engineers start to freak out.
Perhaps in part because they feel, deep down, that an Excel sheet is superior in terms of user-friendliness, capabilities and ergonomics, to whatever the "user viable product" company is trying to sell? A platform may serve different purposes, so the technical challenges, even if self-inflicted, don't seem pointless.
In my experience these folks are the exception rather than the rule. To recognize when, and when not, to use Excel vs. buying/building/subscribing to specialized software, takes a certain kind of real-world experience as a user and/or stakeholder that many engineers surprisingly lack, even long into their career.
If building platforms is cool then everyone wants to be there. But if building products is the thing then people want to work with this.