It depends.

Hateful as spaghetti code may be, there’s also the plain fact that it has worked in production for a while and has accumulated various bug fixes too. If you start over from scratch, you have to redo everything, including the parts which happen to be decent (which is the majority of the code even in most “bad” codebases), and you will likely run into half of the same bugs all over.

You are almost always better off refactoring the spaghetti code iteratively as you work on it. Instead of adding just one more hack to make something work and deferring the proper implementation for later, clean up that one corner of the code you’re directly working on, as far as is sanely possible, and add your change on top of that. The right way to do this, of course, is by writing tests for the part of the code you are about to clean up, so you can be confident that your cleanup doesn’t break anything. Over time, the codebase will slowly tend towards sanity, and as you go along you will progressively accumulate a test suite that will give you confidence to attack the code more aggressively in the more seriously broken parts.

Most of this work is quite mechanical.

Very few codebases are so hairy and disastrous that throwing away the good and known working parts they contain is justified.

Makeshifts last the longest.