List views are actually considered "filters". You're correct though that they're ultimately processed as queries. If you're familiar with the query optimizer that's available in the Developer Console, you may want to use it to help you with your filters. The more indexed fields you use as filters, the more selective your query is going to be.
It's my understanding, that Salesforce's query engine is somewhat dynamic and evaluates how to run a specific query at run time. Sharing is one of those considerations. A worst case scenario would be for a user who's an admin that can see essentially everything. Those are the ones you want to optimize your queries for. The engine will then further decide on its own how to take sharing into consideration by chunking down blocks of records a user doesn't have access to.
The most difficult filters for the engine to process will be the following ones:
- Negative filter operators ( !=, NOT LIKE, EXCLUDES )
- Comparison operators paired with text fields ( text_field <, text_field >, text_field <=, text_field >= )
- Leading % wildcards ( LIKE '%somestring', trailing % wildcard are far less an issue ) Note: this is the equivalent to 'contains' which is an absolute performance killer and should be avoided if at all possible.
- References to non-deterministic formula fields ( e.g. cross-object formula fields )
My suggestion is to look at your equivalent query with the "filters" applied to determine it's "cost". A cost > 1 means that it will involve a table scan which is not good for performance. The greater the size of your database, the more difficult the query will be to perform, and thus the slower it will be.
If your query falls into this situation and you're not able to make it more selective, you may need to enlist Salesforce's help to have them index a particular field or create a skinny table for you. Indexing additional fields will slow the database down during DML, so isn't an especially desirable thing to do.
In the specific query you cite as an example, you don't use any indexed fields in your WHERE condition that include Id, Name, OwnerId, CreatedDate, SystemModStamp, RecordType, Master-Detail Fields, Look-up Fields, Unique Fields or External Id fields. Including any of those would help make your query more selective. Although Id is indexed, you're not providing an Id in your WHERE clause. Industry is not a RecordType. Consequently, you're not using any indexed fields in that particular query to make it a selective query.
That means your query requires a Table Scan (every record must be read to find the results). That isn't a function of permissions, even for those who don't have permissions to see all the records, for every record they can see, it would require a table scan.