With regard to LIO on unused indexes, there are at least two possibilities:
1) Any DML (inserts, updates, deletes) may require modifying the index keys....traversing the index (of course) will use logical reads or physical reads as required.
2) Any maintenance operations (update stats, dbcc, etc.) may hit an index
..possibly more (e.g. iso 3 reads with next key locks, etc.)
With respect to indexes/tables NOT in monOpenObjectActivity - remember, this is not a table - it is a virtual table built by scanning internal structures.....in the case of monOpenObjectActivity, it is the IDES descriptors. As a result, tables/indexes not in cache will not be in monOpenObjectActivity. This can be due to a variety of factors such as table was never queried - or it was flushed from cache due to 'number of open objects/number of open indexes' and DES reuse. If you are not seeing any DES reuse and you collect monOpenObjectActivity for a long enough period of time (e.g. multiple weeks), then it might give you a good picture....remember, of course, that some indexes might be created to support end of week/quarter/year reports that run dismally without them...so you want to be careful in dropping indexes.
I wouldn't used Operations=0 for IndexID=0 as an indication that the table wasn't used....not sure if that is a valid assumption. The fact the DES is in cache suggests there were queries or something that affected the table. It is sort of true that if the only queries are completely covered queries, that the table pages might not ever get read.....but....the table is still necessary to support those indexes. The bigger question is whether the only reason the table DES is in cache is whether due to sysadmin operations...answer is simple - if you use a needs based check vs. arbitrary, you would likely skip maintenance on that table...sooooo.....
