Every byte counted
My 'favourite' feature related to the storage of numeric constants that formed part of a line of BASIC. As background, you have to bear in mind that the machine was very storage constrained, but also very performance-constrained, especially when it came to FP arithmetic.
Say, for example, you had a line
10 LET A=1
10, as the line number, was stored in 2 bytes
LET was a keyword, so was stored as a single byte token
A and = obviously took 1 byte each
But then came the numeric constant 1. Due to the performance hit of parsing that into an 5 byte FP representation (1 byte exponent, 4 byte mantissa), this was done as the line was entered, so what actually ended up in memory was the code for the character 1, followed by the marker byte 0x7E, followed by 5 more bytes of data.
Horror! One character took 7 bytes!
It was actually more efficient to write instead
10 LET A=PI/PI
because PI was, again, a single byte tokenised keyword, so now you had 3 bytes instead of 7 - a substantial saving and one that would add up over the length of a full program.
Similarly 3 was INT(PI), and arbitrary constants were, IIRC e.g. INT("12345") (still saving 3 bytes).
You got the performance back by writing every-increasing amounts in machine code (process: write it out, then hand-assemble, then create a hex entry utility, then type in the entire codebase in hex)
And you saved bytes in your machine code by referring to your disassembly of the entire ROM (published as a book - https://k1.spdns.de/Vintage/Sinclair/80/Sinclair%20ZX81/ROMs/zx81%20version%202%20%27improved%27%20rom%20disassembly%20%28Logan,%20O%27Hara%29.html) to see if you could abything from a full routine down to a few bytes here and there.