@drq I can think of a problem that could save you from: someone amending something in one of these methods and breaking it. If in a painful twist of dysfunctional testing the broken code reaches production, only a part of the app is broken, not the whole thing.

(Depending on how intertwined their uses are though, the parts that remain working would be better off being firmly broken rather than doing their job halfway…)

I'd go for a different angle: good redundancy saves you from problems that could feasibly happen and only when the alternatives are even less viable.
The outcome doesn't really change though, this particular redundancy can be made useless through some basic testing before each rollout. Though, hey, testing can be hard too!

Ugh. Software.