Solidity – Why uint8 Costs More Gas than uint256

Deleting something in storage (setting a non-zero to a zero) does indeed lower the gas cost, but there are a couple things in your code that are making this hard to see:

1. voterList.length-- already has a side effect of setting the "removed" value to zero, so the delete voterList[voterListLastRow] is redundant. Adding it costs an extra 5,000 gas (the cost of storing a zero).
2. voterStructs[voterId].voterListPointer = voterList.push(voterId) - 1; means that the first voter added will have a voterListPointer value of 0. That means that delete voterStructs[voterId] on that first voter will again just be an extra 5,000 gas. (No refund will be given because the value was already zero.)
3. The votesCast field in this code is always 0, so clearing it is always an extra 5,000 gas.

By adding those two lines, then, you're adding 15,000 gas (5,000 * 3 because you're writing three zeros) and getting an extra gas refund of 10,000 or 15,000 (depending on whether it's the first voter in the array). Recall that the gas refund can give you up to half of your consumed gas back, so even in the best case, you won't actually break even.

Edited Answer

The reason people like using uint256 for most calculation is that OpenZeppelin has a SafeMath library for uint256 that prevent number overflow for sol version < 0.8.

Additional casting will cost gas, so it's more efficient to keep number as uint256, and do math calculation all in uint256, instead of reading a shorter bit number and cast it to uint256.

Storage cost optimization you can do

The compiler automatically pack smaller numbers into a 256 bit size storage slot according to the rules here. If you have multiple variables that don't require full 256 bits, you can define them in order to benefit from this batch read or store. After Berlin hardfork, accessing the same storage slot twice in the same tx is cheaper than 2 different slots, so you can save quite some gas by designing our memory layout for sure.

Using struct

I think a relatively neat way to manage memory layout is by using struct, because each struct will start from a new storage slots, so it's easier to manage what can be batch into a single SSTORE or SLOAD, you can also design different struct to suit your business logic better.

A good example can be found with Ribbon finance's code base here. This can save a lot of gas when u wish to write a bunch of variables in the function call