That definitely does not sound right. In fact the reason we built Explorer in the first place is to enable more API-focused implementations that did not need the extra weight or attack surface of a Web Reports instance. In terms of tooling, Explorer behaves closer to a BESConsole cache than the UI-focused Web Reports.
That said, the behavior you’re describing (where a computer drops out of the result if it had not reported a result for a property) is actually the expected behavior; I would expect you would have needed to apply your workaround for a query result from Web Reports as well.
As for the performance - are you comparing the new query on both Web Reports and on Explorer, or are you comparing the original query on WR to the new query on Explorer?
I see your new query can be made much more efficient. What’s happening now, is that for every computer result, it is repeating the lookup of the property definition for each property. Read through the technique at Efficient Session Relevance Query for Computer Properties to make this much more efficient by looking up the property definitions just once, and the retrieving each computers’ results for that property directly.
I’m afraid I’m away from computer for now and I can’t refactor this on my phone, but I’m very confident you can get a much faster result from refactoring the query.
That said, I’d like to hear your use-case if you want to use Explorer but not make it the default for processing REST API queries. If you engage with Support I think we do have ways to direct the root back to Web Reports by default, but I’d discourage it because Explorer should be more robust in most cases.