My counter-argument is as follows:
The CommonMark specification is a specification of CommonMark, not specification of HTML. Unlike in HTML, in GFM-like tables, the cell separators actually IMHO behave more like inline marks, not block marks. They don’t allow to specify any multi-line contents, do they?
Currently not. But it would be desirable to support multiline and block-level content in table cells in the future, and there have been some proposals about how this might be donee
Also, I believe we don’t really need to do any inline analysis for the pipes in most lines to determine whether to start a table or not: The 2nd table line (i.e. underline of the table header) is imho specific enough to be used as an indicator of a table. And for that line you don’t really need full inline analysis either, you can specify it similarly as a Setext underline is specified.
It’s not just a question of recognizing when you have a table. It’s also a question of splitting the cells in each row. For that you need to be able to distinguish pipes that serve as separators from pipes in other inline contexts (code spans, math, etc.).
But I do agree that it would be possible to treat | an inline element called a “cell separator” that would have a context-sensitive meaning: in a paragraph it would simply render as a literal |, and in a table row it would split cells. This approach would require making tables a part of the core spec (which is not a problem really). This is certainly an approach worth considering.