I suspect that the giant explosion in primitives for a screen reader to deal with had actually made the job harder.
And this is ignoring the explosion in nested divs that most modern sites have.
So, it's true that screen readers have heuristics for detecting layout tables. But those heuristics aren't perfect. They're not even that sophisticated, at least the ones that I worked on. And some (most?) screen readers automatically announce any table that they don't detect as a layout table, even when continuously reading straight through the document. Notably, the screen reader I developed myself, which was the first one I routinely used, doesn't automatically announce tables unless the user is manually moving through the page, because I wanted to minimize verbal clutter when casually browsing the web. But when I went to work at Microsoft and started using Narrator to read my work email, I found the tables in certain HTML emails very annoying. Granted, Narrator didn't yet have a layout table heuristic at that time, but even when it did, that didn't entirely solve the problem. Luckily, there was also an overhaul in Narrator's verbosity levels while I was there, and that allowed me to eliminate the clutter of layout tables by reducing the verbosity level in my personal Narrator settings, perhaps at the cost of missing some other things.
Nested divs per se aren't a problem. Implementing a widget as a div without the appropriate ARIA markup is a problem.
Html email feels like a trap. They are about turning up the volume and getting returns. Not about being accessible. Is that not the case?
My gut is still that better tooling support for standard messages would have helped faster than more primitives in the message. But, I welcome evidence that I'm wrong.
Nested divs aren't that bad. (Ignoring overall performance considerations. And even then I'd suspect that's less a concern than download and running all these JS libraries.) Nested divs with a mish-mash of poorly applied ARIA can get pretty bad though!
Table layouts are also terrible for anyone who is not viewing the site at the browser width you designed it for. Accessibility is more than screen readers, and the ability to zoom or adjust browser width or display on a different device (hello mobile) is incredibly valuable for a lot of people. And I'd argue that the "ease" of using table layouts disappears as soon as you try to accommodate for any of that.
Then think of it this way: it became easier to make the content/UI both good looking and fully accessible (e.g. to screen reader users, for whom layout tables are indeed a hindrance).
I think the same applies to the other hoops to jump through; they're solving a real problem, just perhaps one that doesn't directly affect many of us so we tend to ignore it.