What are the deficiencies of the built-in BinaryFormatter based .Net serialization?

If you mean BinaryFormatter:

• being based on fields, is very version intolerant; change private implementation details and it breaks (even just changing it to an automatically implemented property)
• isn't cross-compatible with other platforms
• isn't very friendly towards new fields
• is assembly specific (metadata is burnt in)
• is MS/.NET specific (and possibly .NET version specific)
• isn't obfuscation-safe
• isn't especially fast, or small output
• doesn't work on light frameworks (CF?/Silverlight)
• has a depressing habit of pulling in things you didn't expect (usually via events)

I've spent lots of time in this area, including writing a (free) implementation of Google's "protocol buffers" serialization API for .NET; protobuf-net

This is:

• smaller output and faster
• cross-compatible with other implementations
• extensible
• contract-based
• obfuscation safe
• assembly independent
• is an open documented standard
• works on all versions of .NET (caveat: not tested on Micro Framework)
• has hooks to plug into ISerializable (for remoting etc) and WCF

Given any random object, it's very difficult to prove whether it really is serializable.