Good points. I think that responsive design is probably one of the biggest use cases for CSS layouts these days, though I don't know that it was a driving force or even a consideration when The Great Tableless War began. In any case, I'm not quite a believer in responsive design either. The short is that, as commonly practiced, responsive design fails to acknowledge the relationship between content and layout. I posted a lengthy comment on this thread with more on that, so I'll spare HN's bandwidth the duplication.
Image slicing was indeed nasty and I don't think it was as much a function of table-based layout as an implementation choice. Some tools were particularly nasty with this, but they were less famously also capable of outputting equally nasty CSS/div based code. So, good handcoding is really required to achieve any semblance of maintainable design, whether CSS or table-based.
But, I think you nailed the history. And, it just happened that table capabilities were remarkably useful for laying out a page. Had this been intentional vs a byproduct of that tag's function, the outcome may have been different. One could literally rename "table" to "grid", "tr" to "row", and "td" to "col" and be most of the way there. Would a separate tag of this ilk that could be additionally styled with CSS have silenced the tableless zealots? We may never know. But, if so, it's amazing to think that all of this upheaval, pain, and lost hours was the result of such simple puritanical ideology.
Such an HTML tag vs. pure CSS construct would have also pointed to the already blurred lines between HTML's suggested role as merely a data container vs. its unavoidable role in presentation. The theory that HTML represents only data still manages to sell itself when we are talking say, paragraph and list elements. This is so, in spite of the fact that, like "real" tables, even those elements are themselves completely loaded with implicit layout information.
We need to embrace the fact that a paragraph tag implies that this element will need to be offset and, yes, the details can be found in the CSS. But, when reading/writing the code, the order and structure are intuitive. We don't randomly spit out a group of paragraphs, then impose the ordering via a stylesheet. Instead, we expect the order to be as it exists in the document. Same with lists and other elements. Likewise, the fact that the structure of the document has implications on its layout even leaks through when using CSS. For instance, assigning a value of absolute to the position attribute of an element, positions it relative to its ancestor in the document structure.
But, it's when "pure" layout is involved that things become murkier. We suddenly want to disavow that the natural layout clues are already there and instead force this unnatural separation into CSS. The problem is that much like with tabular data or a series of paragraphs, all content on a page has a relationship to other content that is best expressed in a natural grid like structure. It's not just visual, but actually semantic. So, it is natural to express this relationship in the markup and leave the styling details to CSS. Perhaps more importantly, it is unnatural to spit a bunch of related content into a document in a completely unstructured fashion, then impose structure in a separate document.
So, let's not repeat the ideological mistakes of the last Great War. Ask your Congressperson to keep the grid element out of CSS (except for styling) and add it to HTML where it belongs! :)