I think it really depends on your content and layout. In most cases, I would not use tables for layout. I find that the less you depend on tables for layout, the easier it can be to just make changes to only the CSS if you want to change the layout. With tables, you are basically tied into a row/column layout, and if you want to change the presentation you need to touch both the CSS and HTML markup.
I second what Fotiman said. I'm working on a site done in 2006 by people with no skill nor self-control. The layout is tables in tables in tables in tables in tables in tables (I'm not exaggerating - in fact I might be underestimating the nesting). And the layout has to be pixel-accurate (You have NO idea how an empty text node can make a day's worth of debugging on IE when you render in tables).
Table layouts are broken by definition if you need to nest more than one table. And I myself never use them for page layouts.
Tables only serve me for two purposes: 1. Rendering something, that is indeed a TABLE. 2. Rendering a pixel-accurate, background-imaged, flexible-width (depending on the width of the text inside it), block, always extending to ~90% of it's container, but in some cases extending the container itself, with a hover subclass and an anchor which has to work on the whole block, contained in a flexible-width, floated block that should not extend more than 20% of the size it's container (ie. a custom-designed button with custom, translatable text on it, placed on the side of something similar to a forum post and exactly as wide as all the other buttons in that space, which are of the same type). And I spent about 5 hours looking for a different solution before I retreated to using a table - it disgusts me to this day.
Table layouts have been out since the late 1990s when CSS started becoming better supported. Today, tables should be used for the original purpose...presenting tabular data. Divs and CSS do a much better job in presentation without the inherent problems tables actually have in some browsers. Following might be useful:
It depends. Both methods have pros and cons. When IE6 finally dies out div-based layouts will be a bit easier. If you're unfamiliar with browser bugs you are entering a world of pain. A world of pain. ;-)
Today, tables should be used for the original purpose...presenting tabular data.
The W3C did eventually switch to a CSS-based layout, but "because the W3C says so" is not and never has been a valid reason for doing something. The reason this topic still comes up is that CSS (incredibly) still lacks a proper layout system [meyerweb.com]. But while big, successful websites like the BBC, Google and Amazon continue to use layout tables, I wouldn't really worry too much about being slated for using them.
A lot of major international business sites still use table layouts - especially those that have large development teams to staff and coordinate. There are practical business reasons for this, even though an all div layout all has advantages and is more inline with more recent technical theory.
I suggest doing what works for your business. After all, table layouts can validate even on a strict doctype. And they can get top rankings and high traffic. Especially when deep nesting is avoided, maintenance can also be quite efficient. One common approach is to nail down the basic "grid" with one single table, and then use all-divs within each grid area. This easily gives cross browser compatibility even with very old legacy browsers. That can be important for a fast moving, high traffic site.
A few years ago one of my sites was getting picked on for not using xhtml - because "everyone knew" that xhtml was the most up to date way to write mark-up, or so the story went. Well, I still prefer to use valid html 4 strict compared to code soup in xhtml transitional (unless xml is a technical requirement) and time has proven that approach to have validity.
I don't mean to disparage the all-div layout approach in any way - I also have that kind of site. For me, it comes down to a business decision in each specific case.