Funny, I had been considering replying to your other comment in this thread advocating for the rewrite. I don't really think you and I would find that we have very different opinions if we could sit down and talk this out over tea.
For example, I agree that sometimes a rewrite is warranted, even necessary. I just don't think this is one of those times.
First, you have to think about this from the client's point of view. To borrow some of patio11's recent wisdom, this is, to them, a business problem, not a technical problem. You, I, OP, others are inclined to look at the code and tell the client, "You have a problem with your code." But, the client doesn't care if the code is beautiful or ugly. They care about just a few things: whether or not they can hire people to work on it, whether or not bugs can be fixed, and whether or not it does what they want it to do. Does it matter to them if the code produces HTML tables as output or stores called code in the database? Nope.
So when it comes to a rewrite, you have to sell that to them as a solution to a business problem that they have, and unlike your examples, that's much harder than pointing to defects on an assembly line or hemorrhaging money. Put yourself in the client's shoes: why should you pay for the software that you already have to be completely rewritten -- and in the end, if you're lucky, end up with the thing that from your point of view you already have -- instead of just hiring a different programmer who's willing to just keep his head down and fix the bugs?
Of course it's possible to make a bunch of arguments to the client that they are losing money on it and that it is a problem they need to address, and if you're really good at that kind of thing, maybe even convince them that a rewrite is worth their money. But it's hard to do, in practice.
Then we have to consider the costs involved. First, there's downtime. To get it done as expediently as possible, they'd have to give up any hope of having any bugs fixed for, what, the next six months at least? They'd be dealing with the very real business problem of angry customers in the meantime, complaining that the software is broken and it's not getting fixed in a timely manner.
Second, there's monetary cost. Another difference between big, ugly software and your examples is that software can be far, far worse in terms of the amount of effort required to understand it before changing it. That software didn't get to be a million lines of code overnight; it probably started out, in its infancy, as maybe a few tens of thousands piled on top of a bad framework. The rest is probably largely business logic edge-cases and lazy programming. There is almost certainly some really important business logic deeply hidden somewhere in that code; one way or another that business logic needs to be in whatever version of the software they're using. If a full rewrite is done, that means either the programmers read and fully understand the existing code before rewriting it, or they build the new version without that business logic and force the business to deal with a problem that they've already had and solved once before.
What would be the cost of reading and understanding every line of code, and then writing a new version? Conservatively, $1/line? Heck, assuming you could somehow side-step that whole problem, what would the cost be for an entirely new version? Still $1/line? And how much smaller could the new version be? 100,000 lines, a 90% reduction from the previous version? That's still awfully expensive.
So I think that a full rewrite for this project isn't realistic. It's what many of us would like to dream about -- taking something crappy, throwing it out, erasing it from the world, building something beautiful in its place -- that's psychological sugar. But it's not realistic.
But what can be done is to rewrite it piecemeal. It's like home improvement in that sense -- you don't move in to a home and then demolish it and raze the entire lot and build something from scratch and landscape it and everything. But, you can move in, and replace a water main one month, put in a sprinkler system another month, put sod in the following month, and so on. You can take a really ugly, overwhelming, huge project and break it down into manageable pieces and fix it one piece at a time.
I agree wholeheartedly that life is too short to work on shit projects, assuming of course that you have the money to be in a position to never work on a shit project. That's why I was pretty up-front about this maybe not being a good project to work on. (And also why I didn't stick with my client's project when I was presented with something really similar to OP's.)