I can do it quicker with less chance of making an error by thinking of 11001011101 (for example) as 1024 + 512 + 64 + 16 + 8 + 4 + 1
Yeah, it's nice for different people to have different preferences.
"below the red line, below the orange line, above the yellow line, above the green line, below the blue line, left of the red line, right of the orange line, right of yellow line, right of green line, left of blue line, right of the purple line."
In my opinion, the point of making a table or a diagram is to illustrate something that's not easy to describe with words.
To me it's actually "find out which line the word lies, then find out the column in that line". Also, it's not only "above/below/left of/right of" a colored line (which really sounds confusing), I've already said it's a process of narrowing down the range. Each line would further shrink the range by half.
you can use an open source SHA256 implementation on an airgapped device to calculate the necessary 4 or 8 bits and then work out the checksum word yourself, ....
The last 4 or 8 bits doesn't really matter. It's meaningless for an attacker to manipulate it. Even if it's manipulated, it costs almost nothing to scan through all the 2^4 or 2^8 possible "mnemonics with valid or mismatched checksum".
... which is superior to trusting your wallet software.
According to my understanding, this lookup table helps cross-checking in two cases:
(1) An open-source mnemonic-processing software like Ian Coleman's BIP39 tool still requires an entropy source, which could be suspicious to paranoids - then this lookup table can eliminate the possibility/risk of rigged/flawed random generator.
(2) A backdoored wallet software can display attacker-controlled receiving addresses which are unrelated to the mnemonic phrase at all - then a paranoid can compare addresses displayed by the wallet and the mnemonic-processing software. In this case the lookup table doesn't really participate, however without the above first step this might not be meaningful.
However to my best knowledge such cross-checking can't provide absolute security. One of the possible reasons is that ECDSA has an inherent side-channel infoleak issue that a maliciously manipulated k-value can generate a signature which stealthily leaks secret data to the attacker.