You want to start by doing some sort of a cost-benefit analysis. You aren't truly going to understand how important it is to simply start over without being able to prove that this is the best approach to take. This is not to say that your gut instinct is necessarily wrong, however you really need to determine for yourself whether it is a case of reluctance or professional pride holding you back from working on an existing product.
As bad as an existing code base may seem, you need to remember that there is likely already a sizable investment in it that your employer won't want you to throw away without really good cause. The reality is that even if you have a very good reason for wanting to throw out the existing product, you are going to need to justify your reasoning, and to make this work for both your team and the company, you are going to need to be able to show not only how much the product is costing and could save if done another way, you are also going to need to show that there is a pathway to your "golden ideal" that won't be prohibitively expensive, and you can be sure that this extra pathway cost is going to be counted against any potential savings you might think you can show for your rewrite.
What I am saying is that this is going to be a lot of work. You need to show what the product is costing to maintain as is, what it would cost to improve it to make it of a better standard, what it would cast to maintain while preparing to move over to a new product, what it will cost to develop a new product, and what the new product is likely to cost to maintain.
The reality though is that no product is actually TOO difficult to maintain. All products may be improved with a careful approach to refactoring and gradual improvement over time. This is also going to be a lot of work, but less likely to be as costly or effort intensive than attempting to justify throwing in the towel simply because the present code base is hard to maintain. When I hear someone say that code is unmaintainable, what I hear is that it is likely the code is unsupported by unit tests, likely unsupported by test/build automation, likely a lot of code duplication, and likely to be a lot of classes and methods that are all trying to do too much. These are all problems which are fixable to a very large degree if a little effort is applied to address them.
In a few very rare cases, you may have code that has dependencies over which you have no control. I'm talking old legacy 3rd party products that are being used by your code base, but which have been forgotten about because they were added years ago, and all of the experts have left without documenting why these products were in use. In such cases you might be justified in starting something new, however depending on the size of your product it is rare that this would justify rewriting an entire product from scratch.
I don't think you can really find a definitive answer to your question. Much of this sort of thing really comes down to you, your team, company culture, time, available funding, and a whole mess of other things. This is the sort of stuff that you really need to sit down with your manager to discuss, and to work out as a team to determine the best path forward.