Everything is ok if the language doesn't grow too much and becomes too complex.
Some commands are already at their edge of complexity.
For example recently I introduced the multiple conditions that are useful but they kill the original simplicity of the language.
(the multiple conditions are: if VAR1 == 0 && VAR2 == 10 )
Working with the text strings is one of the problems of quickbms, the existing commands do their job but they are not flexible.
And they have even strange operators like >> or << that complicate the things if you have no access to quickbms.txt and its examples.
Anyway 99.9% of times there are no strings manipulation for extracting archives.
Character/Charset encoding may be possible, probably there is a Microsoft API to do that but then Linux would remain uncovered and it's not acceptable.
So I should rely on a library but that's not ok if the library is bigger than the whole quickbms source code.
Also in this case, 99.9% of times this is not needed for file extraction.
The encryptions you mention already exist and you can apply them also to strings:
encryption xor "\x11\x22\x33\x44"
String VAR e VAR2 # till end of variable
String VAR E VAR2 # NULL delimited
Also that thing of the text blocks is possible using comtype with a memory_file or:
String VAR c VAR2 # till end of variable
String VAR C VAR2 # NULL delimited
"programmatic tons of file manipulations", changing some bytes is ok but making tons of manipulations seems out of the scope of the tool.
After all if someone wants the maximum freedom of doing anything on a file... well probably he will use a real programming language like Python or C and not a tool for extracting files
Hope to have clarified the scenario in which QuickBMS operates.