> To be explicit, I'll use "Give me a list of all my customers in Oregon who have made a purchase within the last year together with those purchases" as an example.

Yes, this maps quite nicely to SQL. Consider this pseudocode:

    for customer in (select * from customers) {
        println(customer.name)
        for purchase in (select * from purchases where cid = customer.id) {
            println("\t"+purchase.date+": "+purchase.amount)
        }
        println()
    }

I know, you're already recalling in horror. But that's because you've grown accustomed to having to deal with shitty implementations of SQL. It is recognized that you cannot actually write code like that under those shitty implementations because your program will quickly grind to a halt as soon as you gain a few customers, but the point here is to stop using shitty SQL implementations and embrace SQL as it as it was actually intended to be used.

Join has a place. This is not it. Joins are for joins in the mathematical sense, not view aggregation.

> I also think that SQL teaching generally emphasizes joins as the natural way to work with relational databases way to much.

Yes, agreed, and I am suggesting that is because of the hacks required to work around the reasons why you cannot write the above code under shitty implementations, which has lead to many conflating joins and view aggregation.

If you want something like the above code except using a declarative language instead then you can throw something like GraphQL in front of it. What are you really gaining by turning SQL into GraphQL?