I was under the impression that screen readers already have relatively powerful table-reading abilities, because the row/column association is already established in the markup and both axises are assumed to be semantically relevant. Do we need to add any controls for tables?

Perhaps ask someone from a11y WG, but my understanding is that there are different modes of reading, and sequential reading might not always do the desired thing. There will be some order to how it is read, and that order might not be according to the author's intent (vertical first or horizontal first), or what is best for with rtl or vertical writing.

Not in the WG, but I encourage you not to apply this to tables.

Table navigation commands in screen readers are robust. When tables are used as intended (tabular data whose relationship is expressed by the structure), the user relies on existing navigation methods to explore the structure to understand the data.

Not only could that make tables suddenly at the whim of arbitrary visual design, but it risks breaking all the understood relationships that come from row and column headers.

As for writing modes, this is easy to confirm as not a concern (unless there is a specific case not cited here that is a known problem). Tables already reflow based on the writing mode.

As it is, I am worried the impact this will have on ARIA grids, which notoriously do not use HTML tables but do use CSS grid for layout. The relationships conveyed to users are the same, but authors are responsible for supporting arrow key navigation within the ARIA grid via scripting (except for ARIA grid mis-uses, where authors fail to do it at all).

Anyway, I am happy to answer questions about screen reader table navigation, tables and internationalization, or ARIA grids. I have experience in all as well as the required assistive technology to perform tests.