You might be right about the ultimate outcome, but I think the questions you ask may be wrong. In the example of changing the checkout to React I might ask myself would it increase development trajectory and look for numbers related to that. Things like how many features were delivered last quarter and what was the scope size of those features? How might these things fit into a react framework and does it improve delivery times on our future project plans? Is our system a proprietary one and how long would it take to onboard a new developer vs hiring someone that knows React and can add value within a week?

It's easy to decipher that nothing is wrong with the checkout page as it exists from performance. What's really being proposed here is an attempt to get ahead of it before it becomes a problem. Keeping the growth needs of an engineering team in mind you have to remember nobody wants to work on a technical stack that uses ancient technology and hasn't been updated because "it's not broken". The evaluation just seems like it's too narrow of a focus the way it's worded here. Just my 2 cents though.