In a way, I could imagine it increasing server costs by like 0.001%, if even that, because if the algorithm finds a post to recommend but then realises it's from a blocked account, it would have to search again (ofc it's probably optimised so that it realises that at an earlier stage).

But we're talking about such small details it literally doesn't matter and is outweighed by the functionality lost one hundredfold.

I expect it's accurate to say; their architecture is not like a database where you can add an index on a blocked state and then join against it. You have to get a list of potential posts that the user might want to see and then eliminate any in the block list. There will be a few edge case users who have thousands of block entries and a multithreading strategy is likely required to swiftly filter it in a reasonable timeframe.

However, an architecture I've seen that works around this is to build this timeline in the background and present it to the user from a cache, I don't know if this is what Twitter does as I never worked on that. However, if you want to not have a block feature but have some kind of mute feature anyway I don't see how there is a meaningful difference.