To give an example of an easy paper-based algorithm, for FPTP you can group each ballot based on the candidate marked and store those as separate piles, and then whichever candidate has the biggest pile wins. Alternatively the piles can be weighed (using a non-electronic set of balance scales if necessary). Also note that the ballot counters only need to decide on the presence/absence/location of a single mark on each ballot, and not decide, for example, whether two marks are "approvals" of two different candidates, or an approval and a crossing out of an approval. These are the sorts of factors which your Excel spreadsheet model overlooks.
I do completely agree with you, though, that IRV/STV in practice tends to be slower than both FPTP and ordinal systems, and its counting process can't be run in parallel, so I would only support it in the circumstance where it was the only reform being offered, and where I was confident that its failure modes wouldn't cause it to be quickly abandoned and used as an excuse to stick with FPTP over better alternatives. Where there is a choice of reform, I support Asset Voting because it retains all the simplicity benefits of FPTP while being resistant to the spoiler effect.
I honestly encourage you to attempt it. Create a fake election and test ballot counting with IRV, Approval, Score, and STAR. The last 3 you can actually use the same ballots so you only need two sets, one ranked and one rated (approval would be scores above a threshold).
I am absolutely certain if you do this exercise you will see that the cardinal systems are far easier. Remember, you are doing many of the same operations in both ordinal and cardinal, but in ordinal systems you have a longer outer loop. In cardinal systems you don't have that outer loop (i.e. dropping candidates). The issue is that you're not considering this into your complexity calculations.
Let's look at the algo again, but in a bit more detail.
While > 2 candidates: # This loop cannot be parallelized
- For each ballot: # This can be parallelized by prefix sum
--preference = argmin(ballot) # The highest ranked. This is a lookup on all rows btw
--preference += 1
--update table of candidate score list
- pop argmin candidate score list
We'll probably make this computationally easier by first sorting each ballot's preference. This will reduce the complexity of argmin
Now Cardinal
For each ballot: # This can be parallelized by prefix sum
- for each candidate: # This loop is trivially parallelized (prefix sum again)
-- candidate score += ballot candidate score
argmax candidate score list # You're doing this on the final score (row), not per ballot.
The second is far easier to do by hand and far more easily done by computers. You're just summing columns. Anyone with an excel spreadsheet can do this. Anyone with the spreadsheet can easily read and verify this too. I would not argue that the same can be said for ordinal systems. Take a look at the NYC Mayoral race[0]. Now imagine if Rounds 2-8 didn't exist. Easier to read and compute, right? What's happening inside each round is pretty similar. The difference is if you're doing += 1 or += score. And with cardinal systems you don't have to sort or determine who the preference is before doing the increment.
I'm not sure where the confusion is here.
[0] https://vote.nyc/sites/default/files/pdf/election_results/20...