I've recently seen an uptick in the number of people who consider the argument “tables are bad” to be mere dogma. Maybe there is some element of that; I don't disagree. It gets particularly ridiculous when people follow up with “well, don't use display: table/table-row/table-cell, either”. So now we're not making a semantic argument, which makes it a lot tougher to justify. There are still flowing arguments and any number of other things, but the position weakens.I'd like to propose that avoiding table layouts is really the development equivalent of taking the stairs. When people talk about small shifts that can counter a sedentary lifestyle, they talk about things you usually don't think about: take the stairs up to and down from the office; park further out at the store; drink extra water so you have to go to the restroom periodically. All of these things force your hand a little, they make you stretch your legs, and they insert small breaks in your day that you can use to let your mind wander a bit. This latter bit is a secondary advantage, not the primary purpose. But it's still powerful. If you don't whip out your phone whenever you take your short breaks or whenever you're heading up the stairs, it's an opportunity for your mind to get a bit creative. Maybe you explore a different set of stairs each day. Maybe you check out the restrooms on other floors, out of curiosity (depending on the office building, every floor may be the same, of course…). It's not that using the elevator isn't possible or necessarily introduces, every time you use it, a huge problem. But by using the elevator every time, you are coincidentally also removing opportunities to think and explore. Every time I run into a problem and the thought occurs “man, tables… They would make things so much easier here…”, it's a challenge. If you've been developing for a while, challenges become rarer—that is the nature of the beast. Most challenges end up translating to experimentation with new features. Here, though, we have an opportunity to explore existing features in a deeper way. You discover properties of certain layouts (inline-block, floats, etc) that you didn't know they had. You gain a deeper understanding of the ones you already knew they had. It's a treasure trove! When I TAed an intro to object oriented programming class, I jokingly argued that a lot of the features in OO that make things easier for a developer stem from the fundamental truth that programmers are lazy. There are some definite truths in that claim. “Laziness” often behooves us as developers because the right kind of laziness leads to better architectures, and it also leads us to avoid premature optimization and a number of other problematic practices. Laziness done wrong, however, also means never growing. If you're too lazy to go outside, you never explore the outside world. As a developer, you want to be lazy in terms of expanding your code base, but not lazy in terms of exploring new solutions. And building in a wall or two here or there that forces you to explore new solutions periodically is a great way to make sure you don't accidentally start standing still. Dogma or not, avoiding tables for layout gives us a chance to explore some fascinating alternate properties in CSS.
For example, I don't know if the fact that overflow: hidden clears internal floats would necessarily have been discovered without the push to leave tables. Even if it had, who knows if it would be as widely-known. And this is a technique that isn't simply a way to clear floats, it gives you an incrementally better understanding of how overflow properties work compared to what you had before. It gives you new knowledge that is tangential to the actual problem you're trying to solve. Avoiding table layouts may be dogma, but I'm going to keep doing it. Every time I get that rush of having solved a particularly gnarly float-inline-block interaction to produce the layout I was looking for, I know I've learned just a little bit more of how these things work together. And I'll be looking for more such roadblocks—ideally these should be relatively small, and should only present themselves as formidable obstacles rarely—in other places, to experiment and see where they are tolerable, where they are terrible, and where they give me the most opportunity to learn. I will, in short, be trying to take the stairs a bit more often.