The main problem is probably that an IE from that era would like to support SSL 2.0, and, therefore, sends its initial message (ClientHello) in SSL 2.0 format, which has about nothing in common with the ClientHello of later protocol versions (SSL 3.0 and all TLS versions). That allowed the browser to connect to a server that knew SSL 2.0 but nothing else, while the ClientHello still documents that the client is ready to use something more modern.
However, modern servers no longer support the SSL-2.0 ClientHello format. There has been a transitory period during which they still accepted that format (even though they would not allow the connection to actually use SSL 2.0), but now they dropped the support altogether. Notably, the SSL-2.0 ClientHello format has no room for extensions like SNI, which explains the urge to drop such support.
Other issues include the following:
IE 6.0 supports TLS 1.0 but it is deactivated by default. I don't know if IE 5 would have supported TLS 1.0, but in any case it would not have been enabled by default. However, many modern server reject SSL 3.0 as well (because of POODLE, as was noted by @etherealflux).
The client code will know nothing of AES, since it dates from before the standardization of that algorithm. It will try to use cipher suites based on RC2, 3DES, possibly RC4 (this would require some verification because RC4 was the property of IE's nemesis, Netscape, so possibly IE 5 would not use it). These algorithms are not a lot popular among server admins nowadays...
Modern sites use rather large cryptographic keys. Typically, RSA with keys of at least 2048 bits. An old Windows+IE might be more limited in the size of RSA keys that it can handle. In particular, a Windows+IE that would comply with the US export rules on cryptography of the pre-2000 era could be limited to a maximum size of 1024 bits for RSA keys. The same combination would also refuse to use 3DES or anything with a symmetric key larger than 56 bits, while no decent server of 2015 would accept anything less than 128 bits.
For Linux-based systems, there is no central SSL implementation (there is often an OpenSSL library, but not something as pervasive as Microsoft's SChannel and CryptoAPI). So every browser will have its own rules. Before 2000, this would have mean Nestcape Navigator (the one that segfaults when it sees anything in UTF-8...). Maybe some early KDE-based browser could do some SSL ? In that case, it would probably use OpenSSL and that should still be able to connect to some servers, with the right configuration (in particular if avoiding SSL-2.0 format for the ClientHello).
