Part of the madness was due to tools that auto generated attributes and browser implementations when repainting/reflow occurred.
If the time, and potential knowledge was there, to better organize the structure vs. the layout thing may have been different. We would probably still be wrestling with browser issues.
I have worked in places where corporate sites had tables were littered with font tags for each cell, littered with a half dozen iframes(!?!)
The use for tables in layout was easy, but the long term debt was never paid.
Granted this is less of a case now; wading through this was not fun.
It's simple as that: if you don't have to (e-mails) do not use inline CSS. Never, ever. And the same goes for <table>. It will actually save you a lot of work.
For example, I have a page that uses html5 to draw a playback progress bar. The canvas tag has an inline style giving the width and height. If I put this in an external css it would mean I would have to either create a new css page, or put it into an existing page (and then put a comment in the css saying which file it was for). Thus the html is larger in total, possibly more files to download, more files to maintain, and if you want to tweak the layout you have to hunt in the css for it (rather than it being right there).
In cases like this where it is a single tag, using inline styles just simplifies development and maintenance with no downside.
And adding a single comment line in addition to your style sheet isn't exactly going to break the bank.
What if your client comes back to you in a few weeks/months and says "I want another playback progress bar on another page"?
I can understand the argument that "you should put styling into an external css so you can just change it in one place rather than throughout the code". However that argument doesn't apply to many use-cases.