To be honest because I wanted to implement the queries
because they are
really needed for me and other bot operators.
We are planning to provide a query API in the near future. Initially this
will consist of an API module that allows finding entity ids based on a
property value combination . Later on we will add a module that takes an
Ask  query, and returns a result object. This means there will be no
need for a ton of different API modules that can all only handle a very
specific kind of query.
 This is the API module I linked in my last email
But I think it would be evil if even the page to query items without
interwikilinks would inherit from the ApiWikibase
class because it provides
functions like addSiteLinksToResult, addAliasesToResult or worse also
attemptSaveEntity which really have nothing to do with quering data. If you
see this functions you have to realize that the ApiWikibase class is only
designed for api modules that edit or get data from one *single* entity. A
module that queries data from *lots of* entities should not be a subclass
of this class but however it would be a ApiWikibase module. This is the
reason why the module should be renamed in my opinion.
I guess you do not understand what I wrote earlier. If one does not have
business logic in the API modules themselves, inheritance abuse involving
functions such as "addSiteLinksToResult" simply will not happen. Sharing
code via inheritance is generally wrong, and the issue you are seeing is
one of the problems it tends to cause. The solution is not to add more base
classes and blow up the christmas tree of classes more, it is to not abuse
inheritance in the first place.
Jeroen De Dauw
Don't panic. Don't be evil. ~=[,,_,,]:3