I recall some of these transactions and researched them.
P2SH was introduced as a soft-fork, meaning old nodes technically didn't have to upgrade - the soft fork could be carried out by a hashrate majority of miners.
OP_HASH160 [20 byte hash] OP_EQUAL
This is the P2SH scriptPubKey. Before the soft-fork, it meant that anyone that knew the value that hashed to
[20 byte hash] could spend the coins.
A quick note on hashrate-majority enforced soft-forks. These are normally invisible to clients unaware of them. The reason is, these soft-forks usually only forbid certain things from happening, rather than allow something new and unexpected to happen.
P2SH is one of these types, because it added further rules to the above snippet of Bitcoin Script. The rule is, if the value hashes to
[20 byte hash], then assume it is a string of bitcoin script and verify it. All this does is prevent some spend attempts from entering the blockchain - they might fail P2SH validation.
From an old version's point of view, if something you allow never happens again, there is no rule violation.
So, why was this block 'mined' 94 times? Well, partially because Blockchain.info uses confusing terminology. They received 94 blocks including this transaction. It's just a pity they were all orphaned!
This is an unfortunate case where the hashrate-majority soft-fork actually caused problems for someone. That someone was in the minority running v0.6, and kept running the older software version (or they forgot to upgrade). Their software a transaction with a valid pre-image for [20 byte hash], and accepted it into the mempool. It then tried to mine it.
The majority, however, had just accepted a rule where such transactions are exposed to additional validation, and deemed this transaction invalid, so they refused to build on top of these blocks.
Regarding P2SH addresses, they are very useful these days. You can request someone to fund a complicated script (like multisig, or a Lightning channel) using a fixed-size address!