The "Read" permission in Alfresco is actually made up of "ReadProperties", "ReadContent" and "ReadChildren". Only "ReadProperties" would be technically required to view a node in a simple listing without accessing any content or sub-nodes. The Alfresco SearchService will always check for the aggregate "Read" permission when filtering results on the Repository tier, because for all intents and purposes, a real UI would require all constituent permission to be granted. Similarily, the SOLR filtering is also based entirely on the aggregate "Read" permission.
The main difference in filtering between SOLR and Repository originates from the difference in static checks and static+dynamic checks.
When SOLR indexes ACLs for nodes, it only indexes the statically defined permissions - essentially, the Repository pre-calculates a set of read-allowed authorities. Technically speaking, the Repository performs a regular permission check but limits the authorities it checks (for performance reasons) to those that have any statically defined permission assigned within the ACL and does not include any dynamic authorities as it calculates the set for an ACL, not a specific node.
When the Repository tier filters the unfiltered results from SOLR, it does a full permission check on specific nodes including all the dynamic authorities that may apply. Of course all facets / statistics returned from SOLR don't have any association to nodes anymore so can't be filtered accordingly.
In a different project we have indeed customized / extended SOLR, i.e. removing some technical limitations of Alfresco SOLR 1.x as well as 4.x (URL length limit issues with facets / complex searches, adding/enhancing support for query facets / filters, minor improvements to cache control), but we have not yet customized anything in regards to permission checking. Most of our customizations are simple request handler facades and don't dive into the actual query internals, which can be quite complex to handle.