There seems to be quite a few different ways to tackle parsing ETW events (TraceProcessing, TraceEvent, ETW2JSON, etc.). I'm interested specifically in the trade offs between the TraceProcessing library and the TraceEvent library.
(I am a developer at Microsoft who works on the TraceProcessor project.)
I have a little more familiarity with TraceEvent than with ETW2JSON, but the same answer applies in both cases.
Each was developed by different organizations within Microsoft to best support our own performance and diagnostic investigations. In some cases, we took design inspiration or cues for TraceProcessor from other libraries, but largely we developed it for our specific use cases and according to our own design philosophies.
Those differences mean that each library has its own principles about performance, API design/consistency, and broad-based ETW support vs. well-developed first-class support for certain specific things.
TraceEvent does have .NET/CLR support, but focuses mostly on being a manged wrapper around the C++ ETW APIs. It does have support for other events, but very limited.
All in all, TraceEvent is great for first-class .NET/CLR data and the "basics" elsewhere.
TraceProcessor gives strong first-class support to the types of system and diagnostic data that you could see in other tools like XPerf and WPA. We’ve pushed for a clean, consistent, performant API across the library and emphasized strong typing to present each type of data in the most natural shape.