I think that's the unfortunate consequence of people without a basic CS background inventing ad-hoc data formats. I recently had to deal with a kind of "nested CSV", where each level of nesting introduced a new delimiter! Who needs recursion?

Escaping drastically complicates parsing (though not as much as quoting, thank god). But you seldom need to nest tables within tables. Much more frequently, table values want to contain embedded newlines.

A general-purpose parser has to be able to handle the possibility of nested tables, so it has to account for escaping. And once you have an escaping-aware parser the choice of delimiter is no longer critical.

Escaping is an unnecessary kludge in 99% of cases. If you need nested tables, then you need a special-purpose format that allows for it--and it will very likely look more like a binary filesystem than a parseable text file. If you don't need nested tables, then escaping is unnecessary if the format uses delimiters which aren't present in the data. A lot of data includes newlines, some data includes tab characters, but only binary data would ever include the ASCII specified delimiters.

Don't get caught in the CS trap of thinking you need a completely "general purpose" parser, when a slightly-less-than-completely-general parser will be significantly easier to write, simpler to understand and debug, and faster to execute. And as mentioned above, if you do find yourself needing more than this parser, then you should be looking at non-parsing based approaches anyway.

Luckily people who designed programming languages had a better idea: introducing some begin and end markers can allow nesting without escaping them. Here I have two blocks nested inside of the outer block but I don't have to escape anything: { { } { } }