Sling Query is not meant to replace JCR queries (XPath, JCR-SQL, JCR-SQL2). It doesn't use indexes and generally in queries traversing large subtrees (like / or /content or /content/mysite/en) it'll be much slower than well written JCR query.
Purpose of the SlingQuery is to provide a convenient way to traverse resource tree. All SlingQuery operations are eventually transformed into a series of listChildren() and getParent() operations .
As a rule of thumb - if you have a complex Java loop reading resource children or parents and processing them somehow, rewritting it to SlingQuery will be a good choice. If you have a recursive method trying to get some resource ancestor, using SlingQuery will be a good choice. On the other hand, if you have a large resource subtree and want to find all cq:Pages, using SlingQuery is a bad choice.
You have a complex logic using Sling Resource API
You want to find resource ancestor
You want to find all descendants with given attribute
You want to find all descendants of given type
You'd like to get ordered results
 - Actually, the find() operation uses QUERY strategy by default, which means that the selector string is transformed to a SQL2 query. However, the transformation process is very naïve and simply skips all conditions that can't be easily transformed to SQL2 (eg. selector [jcr:content/jcr:title=some title] won't be transformed as it contains some subresource reference). The result of this query is then filtere manually. See searchStrategy for more details.
Since this Feature is not available OOTB, you can download bundle from Bundle