I've come to accept Conway's law, https://en.wikipedia.org/wiki/Conway%27s_law, that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

If you are new to a company and are dealing with legacy code who's logic is messy and the solution seems to be a 'rewrite', there's a high probability the new codebase will be as messy as the old one. Even if you aren't new in an org and yet your legacy codebase is a POS. It's highly likely given the same org doing the rewrite that it'll end up as a POS as well.

So if you are making the code 'simpler', getting rid of layers of abstraction to enable a pivot that never happened, you might run into a CEO who still wants that to be an 'option'. A plethora of special cases all piled on each other probably resulted from no single source of truth on requirements in the org. All of these things will still infect a rewrite from scratch.

Its much better to look into specific parts of the code that time can be taken to refactor properly. The time part is critical.