I keep having problems with 504 gateway timeout when I try to submit this kata.

A good heuristic for deciding between the ternary operator and if/else is whether you are choosing between side effects or between calculations. For example:

if (employee.isBoss()) {
    status = employee.notifyDirectReports();
} else {
    status = employee.notifyBoss();
}

Here it should be clear that the choice is between two actions. Contrast with:

pay = employee.bonusActive() ? BONUS_RATE * employee.hours() + employee.bonusAmount()
                             : BASE_RATE * employee.hours();

In this case we're choosing one of two calculations. You could rewrite the first example to use the ternary operator, but then it's easier to miss the side effects.

There is a strong tendency for beginning programmers to want to use language constructs to make code terser and denser than it should be, without considering the factor of readability. It comes down to the question of whether you have the experience and/or discipline to use the ternary operator when it's appropriate and not just because you want to see if you can fit something on one line. If you're not disciplined enough to consider the pros and cons each time you use it, then it's best to err on the side of verbosity. The same argument holds for the ++ and -- operators and other shortcuts.

That's not to say that you personally aren't good enough or experienced enough, but if you think about a policy that has to cover a whole company or a whole open source project, you need rules that will prevent the worst programmer in the group from writing bad code, and so you end up with more always / never prescriptions.

One last thing: Different languages vary widely on how verbose coders tend to be. Things like the ternary operator and using short-circuiting boolean operators for side effects is much more tolerated in JavaScript, for example. The best advice is to try to match what most people are doing for your given language and platform, since it will make it easier to adapt to any given code base in that language, and easier for others to give feedback on or contribute to your code.

That was a fun challenge. Kept catching myself using a stray 0 or ''.

That was darned clever. Fun kata!

I must be missing something; it seems to me that the test cases include asserting that store.delete('e') should return true, but the test code never caches anything under the key 'e'. Other than that, this was a fun challenge!

That was fun. At first I accidentally parsed the operators as right-associative instead of left... that took a while to figure out.
Good challenge! I agree that adding exponents would be a fun extra - that way you have a combo of left-associative and right-associative operators.
I kind of felt like the point about unary minus never having whitespace between it and a number or open-paren was a bit of a red herring - I had to get to the point of a token stream and already be parsing to be able to tell the difference between binary and unary minus. I guess I could have included whitespace in the token stream and then added strict syntax checks, but that seems out-of-scope for this kata.

That was kind of stupid, I had to guess the TITLES array. It's supposed to be predefined, but it's not.

Fun kata, my only complaint is that you should expect a bound function to return a Nothing if it gets a non-Maybe instead of throwing an Error.

That was fun! Tried an extra-functional approach. Good lesson in having a more exhaustive test suite.