Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media.
Yea if it's "non-visual" yea you have to use a div or the space would be used up and just blank. But I can not think of a reason one would need "2 <div> elements to be positioned side by side" if they are not going to be seen (non-visual). Positioning is all about the visual, you want it to look and work good for the user.
Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display.
Well a good site designer will make sure that doesn't happen (ie. properly sized images). The only time I can think that this may occure is if the site has visitors uploading pics. And if that is the case one of 3 thing has to be done; either you have to resize them when uploading, make the box the image is in scroll or leave it so the page can be scrolled. Of those, the first two are a little more difficult.
To minimize these problems, authors should use style sheets to control layout rather than tables.
Hey, I for one am all for that to work. But in the real world, each browser seems to have a different way of handling position, padding, borders, and margins.
Tables just solve 90% of the positioning nightmares that all the browser have created. For the other 10% of the time, all I can say is, yea right good luck, might want to find a different way to do that. A div that is solely dependent on a css or styles is a mess just waiting for the next browser or browser version to be released.
I started out using tables back before CSS. And then when W3C relased there standards I though great an easier way to do it. Then I found I had write out script that identified each browser and browser version and then for each of those I had to write completely separate pages. I got tired of having to do 3 and 4 times the amout of work and went back to tables combined with css, and I have only had a couple cases were I had to code differently based on the browser, since.
Now both of our code examples above will work but yours will end up longer. With yours, you may also end up needing code to determine which browser is being used. And then for those browsers that display it different, than you intended, you will have to write all that out for each one. This makes your example at least 3 times longer than what you have. Where as mine will work fine in all W3C compliant browsers.
Two saying's come to mind, "K.I.S.S." (Keep It Simple Stupid) and "If ain't broke don't fix it" (or as for browsers "since the one is broke don't use it to fix the one that isn't broke").