The performance of such a design would not scale up well. It may work in small/medium environments though.
The Windows Event Collector is designed to do just that - scale up on a massive level. A single collector server can collect from hundreds or thousands of computers, 10's of GB or even 100's GB per day.
On comparable hardware, a pull subscriber approach on a SQL server would not come close to matching the performance of the Windows Event Collector. And a push subscriber approach on a SQL server - even with minimal indexes would be flattened like wile coyote long before reaching anything that a Windows Event Collector could do.
And you would not want to compete with the inserts, so in large environments, a reporting database for queries may be necessary, especially if you have a lot of related tables or carpet-bomb them with indexes. So at scale the solution would not be able to compete on either performance or cost.
There is a significant impedance mismatch in performance between the Event Collector and SQL server. That's why the Event Collector is such a good fit as a transformation intermediary. The transformation apps/scripts that read the Forwarded Events log are inexpensive and easy to build, so there is no business justification (green stuff) for eliminating them. The SQL server would only need a single database - no need for a reporting database, and could be of modest capacity, because the transformation could be performed in large batches with minimal impact on the database server.