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.