At the end of the day, it really doesn't matter. Use the option that you find most comfortable and is the best fit for your particular set of problems. The rest of the examples in this book will however be using the Query object.
What is more important to remember is that when using page objects, our page objects are going to abstract away all of the heavy work of actually driving the browser. Things that we want to check should be in our tests.
This separation of concerns has two benefits. First of all, it ensures that people do not inadvertently bring assertions into their tests when they don't mean to. Secondly, it means that your tests do not depend upon specific implementations in your page objects. You don't want a test to lose the ability to fail because somebody updated a page object and removed an assertion that shouldn't have been there in the first place.
Remember, a test that cannot fail is worse than no test at all. If there is no test at all, you can see that a specific area of code has no test coverage (or in other words, no documentation) using static analysis tools. Tests that cannot fail are incorrect documentation that may be lying to the user when they describe how the system works. The problem is that we will also never know when they are going to start lying.
We are going to make sure that our page objects provide some nice, clear, and descriptively named functions for our tests to use. We are not going to use our page objects as a glorified WebElement store. If we did this, we would not be utilizing the full potential of page objects.