Doesn't your question include its answer? Guilt is not a very productive motivation.
I've noticed that once people settle on something as "the" right way, they measure everything against that yardstick. This is so common, I wonder if having a yardstick -- an easy way to answer questions -- is the purpose of settling on "the" right way in the first place.
Software people do this a lot because software projects are so uncertain: if you can do anything (computable), why do X rather than Y? That's overwhelming, so we look for paradigms and processes and yardsticks. These reduce hard questions like "is this good" to easy ones like "is it standards-compliant". It's like the drunk looking for his keys under a streetlight, rather than down the block where he dropped them, because the light is better.
I noticed this when everyone around me was equating "good" programming with "object-oriented" programming. It was too hard to answer "is this good", so people instead would answer "is this OO". I caught myself doing it one day and was shocked. I decided never to use the phrase "the right way" again, but always to replace it with "a right way".
The trouble with the yardstick instinct, of course, is when it produces fake reductions. It gives you false positives ("it must be good because it's OO, CSS, or whatever") and false negatives ("it must be bad because it isn't"). I think the false negatives are more harmful than the false positives; they shut down options and inhibit creativity. There's a joke in which a Frenchman says to an Englishman, "I can see it works in practice, but does it work in theory?" (Told by an Englishman of course.)
Coming back to CSS vs. tables: if it looks good, is fun for you to make (apart from guilt), and does what users want (or will get you there), what's bad about that? Conversely, if it's hard to make, not fun (apart from guilt relief), and doesn't make things look better or work better, what's good about that?
This is way more than I intended to write, damn you, but one more thing: if you haven't, go read Adam Bosworth's classic 2004 talk on the web as the triumph of the "simple, sloppy, and flexible". I can't recommend it enough. It addresses all of this profoundly.
Edit: Surprisingly, it hadn't been posted to HN, so I just did. http://news.ycombinator.com/item?id=447086
Edit 2: Whenever I recommend that piece to someone I go back and re-read it. How's this for apropos:
What is more, in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it. And yet, ask any gifted web author, like Jon Udell, and they will tell you that they often use it in the lazy sloppy intuitive human way that it was designed to work. They just pour in content. In 1996 I was at some of the initial XML meetings. The participants' anger at HTML for "corrupting" content with layout was intense. Some of the initial backers of XML were frustrated SGML folks who wanted a better cleaner world in which data was pristinely separated from presentation. In short, they disliked one of the great success stories of software history, one that succeeded because of its limitations, not despite them. I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules - XSLT, and Formatting- CSS) would have had anything like the explosive uptake.