Making a feature request for your first post is never a good idea.
If you want to do arithmetic, the python plugin is the perfect solution. It is simple and easy to do and there is no practical advantage to creating a whole new math parser (by no means a simple task) within the program to accomplish the same thing. There is no downside to using python for this other than a possible issue with two letter combinations that remind you of words that remind you of scaly animals that you don't like. Try to think of it more as a badly spelled dessert.
Your example of
"bri":{1}*2 would be virtually impossible to parse intelligently in terms of interpreting all the possible variations of action parameters and variables we are already using.
Kalle was suggesting that you could map integer phrases ranging from 1 to 100, to values from 1 to 255 in your payload xml. The same way you are doing it now, but with more entries. Or maybe that's not what he meant... but you could do that.
I see no point in such fine grained control of the hue brightness since there is not a huge difference between 10% and 20% brightness, but that's a personal thing.
In this particular instance using the % feature in the hue parameter makes the most sense, but if you needed to do the math for some reason it is only a single extra action
PY.ExecString result={1}*2
and later "bri":{LastResult}