"Polyglot programs" are useful in many contexts, notably for sharing some common settings in a centralized place instead of having to edit multiple files and having one of them out of sync.
Thanks the Lua interpreter supports the hash-bang syntax on the first line, that's why it works.
Another way to do that is to transclude a code fragment (generally a set of variable assignments: this works simply like a basic .ini file or .csv file (you may need to add comment separators between lines to hide some additional separators that may be needed between them).
Generally, this approach is simpler as there's less "quirk" intro.
The last alternative is to write tools that will generate config files for different languages from a source config (written in any input format suitable for that tool). But this requires more discipline and a chain of actions that must be followed scrupulously, otherwise, you'll get also out of sync and the results are unpredictable.
For some languages, allowing them to be "polyglot" is more difficult as they have stricter syntactic rules (e.g. Turtle data or RDF) and they require complex escaping mechanisms.
Also, not all of them support multiline block comments or arbitrarily long string literals.
Being "polyglot" does not mean you'll write and maintain a full software with this format as it would be very impractical, but at least you should be able to "package" your software with it. Historically it has been used since very long for file archives (consider the old "shar" format: shell archives on *nix)