An EUDVariable is a trigger containing exactly one SetDeathsX action. The value lives in that action's number field, and reading or writing the variable means reading or writing that field.
A trigger is 2,400 bytes in the map's chk structure, plus 8 for the two node pointers in memory: 2,408. Yet a variable is said to cost 72. Both are true - 72 is the cost of one MORE variable. A hundred of them come to (100 - 1) × 72 + 2,376 bytes.
The most revealing part is what happens when you pass a variable as an argument. The value is not copied: the destination address of the variable's own SetDeathsX is rewritten at runtime. A variable is less a thing holding a value than a trigger holding where to put one.
This is where "reads are expensive and writes are cheap" comes from. A write is one action. A read has to move the value through several triggers to wherever it is going to be used. So reading once and reusing beats reading the same value repeatedly, and it is the same reason the functions ending in _cp are faster: fewer steps to go through.
This is not an argument for hoarding variables. 72 bytes is cheap and readable code is worth far more. The point is knowing why a loop that reads the same value ten times every cycle is slow - and why it does not look slow when you read the code.