> The idea is nice, and probably a step in the right direction, but
> `org-at-table-p' and `org-table-align' are not lightweight functions. In
> some common situations, e.g., when the table is a bit large, or when it
> is located away from the start of a section, typing in the table may
> feel sluggish.
>
> Therefore, I wonder if Org should include it unless it is optimized in
> most situations.

Apparently, the code is more like a proof of concept, not a fully
optimized solution. I didn't mean it should be included as is, rather
the concept itself is very promising and provides a better user
experience. As some of the commenters put it on reddit this is how
they expected Org tables to work in the first place and I feel the
same way.

As for org-at-table-p being slow storing the start and end position of
the table could be a solution, so if point is between them then there
is no need to check org-at-table-p again.

org-table-align seemed fast enough for me when I tried the posted
code, but if it's slower for large tables then the code could measure
the time it takes to perform the alignment for the current table and
if it's above a certain threshold then it could introduce a bit of
idle delay for the update, so it doesn't hold back the user from
typing, and if the alignment is fast then it could perform the update
without delay.

Anyway, I think if implemented properly then this feature could be a
worthy addition to org, even as default if it works well, because it's
a much better user experience and a much better first impression for
new users, instead of the current default fragile table which falls
apart during typing and fixed only when TAB is pressed.