To give a concrete example, take a look at the DNS root zone servers operated by Verisign. They run a 50:50 mix of Linux and FreeBSD and increasingly a mix of BIND and Unbound. They use a userspace network stack on some and the system network stack on others. If someone wants to take out the root zone, they need to find exploits for each of these systems. A bug that lets you remotely crash a FreeBSD box likely won't affect Linux and vice versa. That gives them a little bit more time to find the fix (they also massively overprovision, so if someone does take out all of the Linux systems then the FreeBSD ones can still handle the load, and vice versa). If someone finds a bug in BIND then the Unbound servers will be fine.
If your web site were running a mixture of OpenSSL and something else, then it would be relatively easy to turn off the servers running OpenSSL as soon as the vulnerability is disclosed and only put them back online when they've been audited for compromises. Of course, it depends a bit on what your threat model is. If a single machine being compromised is a game-over problem, then you're better off with a monoculture (at your organisation, at least). If having all (or a large fraction) compromised is a problem, but individual compromises are fine, then it's better to have diversity.