This answer seems to be a bit harsh. Turning FIPS-140 compliance mode on does in fact provide some protections. It prevents the use of weaker crypto schema, which is protective.
This can be inferred, actually, from the comment above that "it drastically reduces the choices the system has" -- it removes crypto schemes that are no longer considered appropriate by the Federal Powers That Be. And as the answer noted, "Turning FIPS 140 mode on turns off anything that's not FIPS compliant". Stuff that isn't FIPS 140 compliant won't be known to work.
Turns out that is a good thing. In the first five years of the crypto module verification program, it was discovered that 25% of the submitted packages had errors in documentation, and 8% had errors in implementation. That is, if you were depending upon a commercial package already out there, there was about one chance in twelve that it was broken, and providing NO protection other than smoke.
But the tone of the message -- that enabling the FIPS 140 discipline breaks things -- is alas, correct. Crypto is hard. Programmers often don't have the discipline to do it right, particularly with legacy software. If one isn't in a federal environment where you must do it, most people don't do it.
But this is apparently changing. Enterprises are expecting disciplined security engineering from their coders. I'm hearing clients say "you know, there is this STIG that the feds use, shouldn't we do this?" Having standards (and FIPS is just "Federal Information Processing Standards") is a good thing, and supports interoperability and accuracy.
So if you enable FIPS 140 mode correctly, you have a good reason to expect that the other side should, if it is properly configured, be able to work in FIPS 140 mode as well. If not, file it as a bug with the system vendor!