I think a definate distinction needs to be drawn between designing with less tables, and tableless design.
Rigidly tableless design is as logically defunct as throwing all of the screwdrivers out of your toolbox because a chisel is good for presentation.
Mythical "CSS-only" chisels cause as much of a mess to the screwhead of any tabular data layout (which may or may not be presented as a table of figures) as a screwdriver would to a woodcarving.
Design with less tables is a process of natural selection. If "CSS-only" (which is an absolute myth anyway) could do everything tables could do, and reliably, and with the same markup overhead, and without being overall more hacky than a table solution, nobody would use tables; even if it were only to escape pre-spoken criticism.
All HTML markup is presentational to a point; HTML has almost none of the useful features a data definition language would have, and yet it's widely spoken as being 'data' that needs to be separated from presentation. All CSS solutions require markup, otherwise you have one element to work with; <body> (and even then you need a little markup).
You'll find, that the best designed websites and the best website designers make good use of the inherant advantages of tables, where and when they are appropriate.
I think it'd also be good to talk about the different types of website. Flashy graphical one-to-five page info-sites that never change unless the "website designer" gets another hefty contract payment probably never need a table. Each page can be carefully designed and tested on every browser version, and it'll always look good because it'll never change anyway.
Sites that present dynamic lists of anything (forums are a good example) will almost always use a table to present something, somewhere. Tables line up their rows and columns, tables are easily visually interpretable, tables can easily be populated from a database. Using a combination of HTML DIVs and SPANs and CSS to emulate a tabular layout for the data is always going to be 150% hacky.
In essence, this is exactly as the W3C put it, tabular data (possibly taken directly from a database table) could be presented in a table, and for the most part, should be presented in a table.
The same applies whether the HTML data is manually entered or automatically generated, provided there is some logical or meta-logical link between "these values" and "those values". In essence XML itself (and thus XHTML, and thus HTML if you agree that HTML is essentially occasionally-closure-implicit XHTML) is an arbitrarily-dimensioned nested tabular structure.
Where the path between data organisation and data layout lies will for the most part, and providing you're not aiming to confuse, fall along parallel lines. I fail to understand why double-implementing those lines could be of any benefit to anyone. Applying positioning CSS to a load of identically classed objects to arrange data that could be better organised seems somewhat backwards to me. Perhaps these CSS-only designers are aiming for totally content-ordered-markup, which seems to be mostly an SEO myth.
If you want to design without tables, definately try it. If you use one table where it's appropriate, you don't design without tables, you (perhaps) design with less tables. Neither way is inherantly wrong.
If it only works in Internet Explorer; it doesn't work.
