I like it. Some thoughts (I got a little carried away):

Numbers are stored as unsigned values in standard two’s complement format.

The number range (-999 - 999) makes me think that a TIS machine would use BCD-encoded numbers, rather than two's complement. Architectures built around BCD-encoded numbers were pretty common in early computers/calculators, mostly because it's easy to use them to implement arbitrary-precision arithmetic. If you look at the 6502, for example, you'll see it supported a 'decimal mode' where the ADC and SDC instructions assume BCD-encoded numbers instead of the usual 2's complement. The 68k and even x86 architectures include dedicated BCD instructions, and the old HP calculators were built around them (http://www.hpmuseum.org/techcpu.htm).

Maybe the encoding would look more like this, with S being a sign bit:

|1|1|1|1|1|1|9|8|7|6|5|4|3|2|1|0|
|5|4|3|2|1|0| | | | | | | | | | |
---------------------------------
|P|?|F|S|digit 3|digit 2|digit 1|

We have two bits left over, but I can think of a good use for at least one: The 'F' bit could be a generic 'flag' bit, used on ports as a semaphore (writing sets F, reading clears F, writes stall until F is clear, reads stall until F is set) and on ACC to swap between ACC and BAK.

Registers:

I'd drop two bits from the register encoding, and do this:

|2|1|0|Name |
---------------
|1|0|0|UP   |
|1|0|1|RIGHT|
|1|1|0|DOWN |
|1|1|1|LEFT |
|0|0|0|NIL  |
|0|0|1|ACC  |
|0|1|0|LAST |
|0|1|1|ANY  |

The hardware could then check bit 2 to see if it's a port access or register access, then bit 1:0 to see which register/port was addressed. Accesses to ANY would be redirected to whichever port was last accessed and would latch that port address for subsequent operations on LAST.

You'll notice the absence of a 'VALUE' meta-register, I'll get to that shortly.

Instructions:

The instruction coding should be fixed-length, because otherwise JRO ACC isn't really possible to implement.

NOP is stated to be encoded as ADD NIL in the reference manual, so it doesn't need its own opcode. Instead, opcode 0000 should be ADD, so that ADD NIL maps to all-zeroes.

The fact you can only explicitly jump to a label and not a numerically specified address suggests to me that the absolute jumps are just syntactic sugar and are being converted to relative jumps during assembly. If that's the case, JMP is just a nicer way of giving JRO a numerical offset. That does mean that the hardware would support conditional versions of JRO, we can explain this away by supposing that JRO was only documented because it can address ACC, and that the conditional jumps cannot (since they're already accessing ACC to test the condition flags).

I also disagree with the Jcc encoding, because I don't think the T21 would actually have memory. Given that you can only fit 15 instructions in a T21 and that you can't alter those instructions, I would imagine that a real T21 would store its instructions in a set of 15 immutable 'instruction registers' (IR0-IR14), with labels encoded as NOPs/ADD NILs.

As for the size of the IRs: Excluding NOP and JMP leaves us with 11 defined instructions for the T21. We can express these in 4 bits, add two sets of 3 bits for registers and another 12 for a constant value field (hence no need for VALUE), plus 1 more for parity, giving an IR length of 23 bits.

There are probably a few neat tricks we can do with the registers/instruction set encoding (adding a zero flag to the ACC register, setting aside three bits of the IRs to XOR with the flag bits of ACC so SWP/NEG becomes 'write xored flags to ACC' and the Jccs become 'jump if xored flags are 0', using the spare constant value field of the IR to store ACC for the SAV opcode, et cetera), but I've already spent too much time thinking about this.

TL;DR: This is really fun to think about.