This is a big topic, and you'll see responses in the IBM community and MORE community (like here: Work Order record Filters (web vs device) | Maximo Open Forum) as well as there is a page in the Developer Documentation wiki that tries to cover this at a high level. If you haven't reviewed the developer documentation link in the help this is an absolute must as there are a lot of concepts in MAF development, mobile differences, etc.
At a high level, lookup datasources are shared across all mobile applications to avoid TECHMOBILE downloading asset data, SRMOBILE downloading asset data, ICMOBILE downloading asset data, etc. Any attributes defined on any datasource across apps is combined. If TECHMOBILE needs assetnum,location,description and SRMOBILE needs assetnum,description,assettag, the oslc.select would be assetnum,location,description,assettag for example. Maximo Mobile will use only 1 saved query for lookup data which is why it's absolutely imperative that you use the same saved query across applications. If TECHMOBILE has a saved query to return all locations and in your custom app you have a saved query that only returns 5 locations, only one of those two datasources can have what they expect.
Transactional datasources (IE WORKORDER, SR, etc.) are downloaded for every app & saved query which avoids the multiple query problem, though there are issues when the schema between apps don't match and the same record is needed by more than 1 application. But that's a topic for another day.
The mobile-qbe-filter (or using JavaScript setQBE functionality) can only be used on top-level attributes. This is why you will see attributes on child objects like asset aliased (asset.description--assetdesc for example) because it moves the attribute up a level in the JSON response which makes these attributes searchable. Searching of child objects (IE workorder->multiassetlocci or locations->locancestor) is not possible. How you build the filter is also different, but I assume you realize that.
You could add a _dbexists type attribute to see if that location is in the hierarchy of your user. That would be searchable on mobile (any field is searchable in mobile because everything exists in the database). But that gets you to the next topic of conversation which is preloaded databases. In Maximo Mobile, you will always see that lookup data is recommended to be downloaded via a preloaded database because it generates on the server in advance of the users logging in and will drastically speed up login times. However, if you use a preloaded database, anything that is user specific like this will no longer be accurate because the preloaded database is generated as a single user (such as MAXADMIN) for all users.
I would recommend having someone familiar with Maximo Mobile customizations to at least bounce ideas off of and understand the best way to achieve your objective. There's at least a half dozen or so approaches I can think of, but each have pros and cons and will really depend on your use case. There's not an easy answer that works best in all scenarios.