Finding the "right" level of abstraction probably is in a constant state of flux -- depending on experience with the technical system, the domain one is working in and the vision where the project might go.
I usually struggle when I'm confronted with abstractions that make the learning curve too steep to quickly get a foot on the ground when new to the system. I'm happy if I find a system (let's say a library) that makes implementing mundane simple tasks easy, so I can assess if it's a good fit for my requirements without spending weeks, and allowing me to gradually learn how the system works, and then move forward to look behind the scenes, and tap into the power of whatever the system is presenting, if I need more power.
If I'm building abstractions myself it helps to have the other people on the project in mind, and ask myself how I can make their life easier. I recently had the situation with a little team of 2 java newbies (who actually were participants in a running seminar I was facilitating in the department), and we were asked to implement a webservice that should get fetch some data out of a database in a flexible manner. Interesting enough the deadline was way ahead of time - our seminar had barely touched JEE, and we had not explored JPA. JPA was somewhat what others in the company considered the way to go, but I felt it to compromise our project success if we need to scrape our data together in an SQL tool first, then translate it by the "human brain transpiler" into JPQL (or even criteria api), find some mistake there, go back and forth between it ... and stumble and fall.
And we also had the requirement to be able to add flexible where-conditions to our queries.
We ended up being quite pragmatic: inventing our own little framework that simply takes a single sql from a file, does some primitive "parsing" to split it into SELECT/FROM/WHERE/... parts. Having this adding any flexible conditions can be hidden behind the abstraction that modifies the WHERE-clause, and we also have an automatic mapping of the database-values to pojos (TOs). Besides that we integrated getting data from another data sources (a DMS), and created a mechanism that adds in data from other tables or data sources if we explicitly tell it to (thus reversing the JPA-idea of automatically fetching a whole object graph, dealing with lazy fetching, etc.).
The SQLs can easily be executed for exploratory purposes in the db-tool of your choice (or even in the IDE), and are nicely separated and maintainable.
It resulted in a kind of cookie-cutter-architecture, and my two java newbies could focus on the business requirements, while I was more in the role of the "tool maker" -- whenever a new requirement arose that couldn't be handled with our current framework it was my job to make adjustments that would enable it to make handling such a requirement easy.
I sometimes felt a little bad about it, as I feared the two newbies would get too little exposure to the java jungle to learn enough, but the resulting system was ready for production in a short amount of time, and the frustration level for the newbies was minimal. Having "abstracted away" many repetitive details also allowed us to easily change certain things in a single location, and even to optimize some slow requests for performance quite easily.
In the end I was quite happy with our approach -- and I'm thinking about retrofitting another project to use this approach, too. I somewhat felt "bad" and insecure by not doing it "by the book" (=JPA, where's that book?), as a sister project does it, but the more projects I see that have to work around the specialities of JPA, the more happy I feel to be an outlaw ;-) ...
So, I'm rambling here -- sorry, if that's not appropriate.
To get back to your initial questions: "relevant" and "irrelevant" details for me are related to the understanding of the business requirements, the prospected path they might develop, and the skill level of the developers involved.
When our judgment of relevance changes -- well, we change the code ;-) ...