If you watch the Pluralsight courses Kehayias does on Extended Events he goes into detail about the events being written to the XEL file. The size of the XML output is not limited to 4MB, the max memory allotted for the ring buffer is 4MB. You will not see an event show up in the event file (XEL) until it has been buffered out because it either hit the limit of max_memory or the limit of max_events_limit. Which are set to 4MB and 5000 respectively for the system_health session.

It is also worth noting that if you use the "Watch live data" feature in SSMS 2012 to view a session that the ring buffer settings are overwritten while the API reader is actively reading the session stream, what the "Watch live data" utilizes in the background. I wrote up an answer on DBA.StackExchange here that shows an example of this.

One thing I have used that has been consistent enough for the clients that utilize it is WMI monitoring. I use almost the exact same code shown in MSDN, with a few exceptions on table names and such. One particular client I simply added in a job step that will email a report of the deadlock information captured, providing enough information that they do not actually have to login to the SQL Server instance to pull it.

Also, reading over a few other post in this forum I do seem to recall there were issues with the system health session capturing multi-victim deadlocks in SQL Server 2008 and R2. I don't remember where I read it but seems like it was fixed in 2012 because of they changes made in the XML format or something...no proof to provide mind you.