Merge request stability is not compromised in an E2E test case scenario.

You seem to have a very idealistic view of software. That's perhaps based on YOUR experience, but MINE is very different. When you have a chain of 3rd-party dependencies (irrelevant why), one having a 10s hiccup will cause a chain reaction. Sure, I have the option of building a 10s wait into the test, but that's actually bad practice. A more practical approach is to still have the original assertion of snappy reaction times, and if at some point that happy path fails, you automatically rerun the test. It will likely pass the second time. If it doesn't, then it's worth investigating or you might already have an alert going on somewhere else about an outage.

Also, handling one 3rd party service sluggishness is not the same as handling 3 or 4, when those rely on each other. I'm talking of platforms with 50+ million users, an orchestration of your own microservices, microfrontends and 3rd party services all having to work in tandem.

I am not stating that what you're proposing cannot be done, but it's not financially viable. Cheaper to rerun a test than account for virtually everything, without having any UX cost/impact.