More technical explanation of the rationale:

Imagine that you have a shell script where you need to dynamically create a list of arbitrary strings. And you need to do this in several places in your code, so you wrap it up in a function.

The only way to 'return' a string from a shell function is to print it out and catch it with command substitution, or to set a variable that the caller then reads.

When you have multiple arbitrary strings (so any of them may have any arbitrary characters in them), if you just do that, you get just one variable containing the string, let's say $FOO. If you use $FOO (unquoted), word splitting may overzealously split some of your strings, or lose characters off the edges. If you use "$FOO" (quoted), then it's be treated as just one really big argument. If you do eval ... "$FOO", you're back to the equivalent of just using $FOO.

Some of the more featureful/bloated (depending on your viewpoint) shells support arrays - in which case you can make FOO an array, and you're set. But we can't rely on array support, since many shells don't have them. It's possible to do wierd voodoo to coopt the positional parameters ($1, $2, ...) as an array, and it's possible to use eval to kludge pseudo-arrays (where $N is some number, and you do eval ... \$FOO_$N ), but the code for that gets messy.

A relatively clean-looking solution is to wrap the strings up with something like esceval, and then make one big string out of the escaped strings. Now when you do eval ... "$FOO", it'll actually parse the "packed" strings into exactly the same separate strings as they were before the esceval.

Furthermore, even if you never have to pass them up to invoking functions, if you have to build the final set of arbitrary strings in a way where you don't have all the strings at once, and especially if you have an arbitrarily large number of strings that you need to 'get' before you can build the final set, esceval (or something like it) is way more legible than using one of the above-mentioned pseudo-array kludges.

It's this code clarity/simplicity, as well as functionality it enables for portable shell scripts, that made me like this approach enough to want to see it become commonly available. Now, obviously given the lack of such widespread-ness, for portability currently, you'd use the shell script variant I have up on github, since that just relies on printf and basic sed syntax, which are portable. But given how much more performant and simple a dedicated C program is, I look at the shell script variant as something that would be best phased out in favor of something more purpose-dedicated than invoking sed every time.