Because start from scratch is more predictable ("estimable") than "dig into how it works". "Dig into how it works" is better in the long run, but will take longer. All software management is laser focused on speed and predictability rather than long-term quality.
I think it's a mistake to make the "fix the old" or "rewrite from scratch" decision up front from a position of high uncertainty about the old system.
I'd go with a strategy of starting a timeboxed exploration of the old system with the objective of understanding it better, hopefully well enough to have a reasonable idea of what it will take to fix it. Then make the decision from a better informed position. Yes sometimes the decision may still be to rewrite because you now know that the old system will be excessively hard to change but in many cases you may find out that the old system wasn't as bad as expected.
Replace-from-scratch has all the same risk of getting things wrong because of that lack of knowledge and a bunch more new-code-writing on top of it. Estimating new development often fails; estimating it in the face of business requirement uncertainty is even worse.
To certain styles of management focused on "always building new products" to guarantee their worth/value, they absolutely will get blinders on and believe "new products are easy and more predictable than maintenance of old products". Those blinders are hard to take off once they get into that sort of pattern. All of their processes are built around "new products". That starts to be the hammer that wants to dismantle old products because they don't do maintenance (that's someone else's problem) but they surely know how to build new products. They are the build new products group, that's what believe they do. Building new products is exciting and they can be passionate about it.
I also think that's generally the wrong way to work and does plenty of harm and creates a lot of unnecessary stress on development teams caught in those cycles. But I've certainly seen plenty of management teams that do work that way in the real world and maybe don't question it enough.
Learning the old system enough to keep working with it, meanwhile, looks a lot like a couple developers staring at screens for months without results that look impressive to anyone who matters (as far as granting rewards goes) and with very uneven progress. Plus they've gotta be pretty good, experienced developers (so, likely expensive), or the risk of breaking shit as they begin trying to change the system, goes up a ton.