[xienze]

> Since it is impossible to force all inputs to be well-constructed, text acts as the more predictable interface.

Disagree. If the program decides to change its output formatting even by a small amount (like going from a GNU version of the program to the BSD version, where such things can happen), e.g. changing the column order of two items, whoops, your script is broken. When you deal with object versus textual output the textual representation of a program can change all day long and you're not affected. The only breaking change is a change to the output object format (like renaming or deleting properties).

Writing scripts that rely on text being output in a specific order with a specific format is very brittle in my opinion.

[makecheck]

Robust scripts require diligence appropriate for the environment. If you’ve deployed systems with different default tool versions, you factor this in, e.g. by installing a common version that both can use (or just make scripts that can figure out how to work either way). Two versions of a tool isn’t really any different than two versions of a compiled-in API, except that APIs tend to be more rigid (not always, e.g. some languages allow runtime querying).

There’s a common rule in Unix-like systems that essentially says “inputs are liberal, outputs are conservative”. It matters to have programs that can adapt, because this makes a lot of things more practical.