Sort:  

Most blockchains are not designed for speed, they are designed to be robust. You think 10 minute block times on bitcoin is fast?
Actually, even better; do you think 3 second block times on steem are fast?

Depends on your perspective. To us humans, 3 seconds is quite speedy. To a computer, regardless of programming language, 3 seconds is eternity. Python could handle 3 second blocks fine, assuming the programmer doesn't insert a time.sleep(3) in there somewhere. It might take a naive python implementation 200ms to process a block, where a C implementation can do it in 10ms. In the grand scheme of blocks, not a big issue.

We're limited by the speed of light distributing a block far sooner than we are at processing blocks on a machine. So in my mind it's a non-issue for blockchain style consensus model. Unless something is really wrong.

True, but what about witnesses?
For a record to be posted on the blockchain, witnesses have to come to consensus, no?
And for that the for loop needs to be inherently fast not to jam the transaction flow. Of course you can mitigate it by running delegated PoW/PoS, hence my question.

Like I said -- we're limited by the speed of light in distributing blocks far more than we are in machine processing time of blocks. Block processing is in the order high micro- to millisecond, where block propagation around the world is high milli- to full second. There's plenty of time to forgive processing language inefficiency. I say this with confidence as a) a computer engineer, and b) a witness here on steem. Latency is the biggest issue for consensus!

If you want to reeaaaally did deep in to what takes longer on python compared to C, you'll find a second non-issue. The stuff that takes the longest amount of time in block processing is transaction verification, which is cryptography. Guess what? Python can call functions in libraries that are actually implemented in C. So, for the biggest bottleneck, you'll get the almost the exact same performance.