I'm not liking what this use of ints instead of strings will do to json readability. 
I don't want to have to memorize or look up the integer code for every operator to understand the json plan.
I find it only a little easier to accept integer codes for valuetypes because there are fewer of them but even that makes me want to reassign them to be more memorable like:

    NULL = 0
    TINYINT = 1 (it's 1 byte)
    SMALLINT = 2
    INTEGER = 4
    BIGINT = 8
    INVALID = 9 (the 9th letter of the alphabet is 'I' for INVALID)
    NUMERIC = 14 (the 14th letter is 'N')
    FLOAT = 6 (F is 6th)
    TIMESTAMP = 20 (T is the 20th letter AND current timestamp strings begin "20...")
    STRING = 19 (S is the 19th letter)
    DECIMAL = 10 for "base 10"
    VARBINARY (V is the 22nd letter)
    VOLTTABLE = 45 (V, the 22nd letter, is already taken by VARBINARY) a table is a "2D" array "2D" in hex is 45. This value will not used very often, anyway.
OR something like this. As an alternative (that I don't like very much) we could use the existing "signature character" that each type already has 't' for TINYINT, 's' for SMALLINT, etc. but then we are back to using quotes (but fewer characters). How big a performance improvement do these integer codes really make?

We could invent similar short codes (one or two characters) for expression types, too, but I think that numbers for expression types will make working with the json very difficult.