There are a couple of potential possibilities, here.
First, BlockingCollection<T> in the Reactive Extensions is a backport, and not exactly the same as the .NET 4 final version. I wouldn’t be surprised if the performance of this backport differs from .NET 4 RTM (though I haven’t profiled this collection, specifically). Much of the TPL performs better in .NET 4 than in the .NET 3.5 backport.
That being said, I’d suspect your implementation will out-perform BlockingCollection<T> if you have a single producer thread and a single consumer thread. With one producer and one consumer, your lock is going to have a smaller impact on the total performance, and the reset event is a very effective means of waiting on the consumer side.
However, BlockingCollection<T> is designed to allow many producer threads to “enqueue” data very well. This will not perform well with your implementation, as the locking contention will start to become problematic fairly quickly.
That being said, I’d also like to point out one misconception here:
…it would probably offer better performance than anything I or my teammates wrote.
This is often not true. The framework collection classes typically perform very well, but are often not the most performant option for a given scenario. That being said, they tend to perform well while being very flexible and very robust. They often tend to scale very well. “Home-written” collection classes often outperform framework collections in specific scenarios, but tend to be problematic when used in scenarios outside of the one for which they were specifically designed. I suspect this is one of those situations.