I'll add that if you want to use ANY of the Domain Aggregate functions (vice SQL Aggregates), you MUST have a QueryDef because you cannot run a Domain Aggregate against an SQL string.
However, I think there is a middle ground to be had. If I have a query that isn't going to change no matter what I do, I put it into a QueryDef. If I have a complex JOIN-based query based on, say, cascading combo boxes, I'll build a basic named query as my base but then build a layered query on the base and have the layer do the filtration. There IS such a thing as trying to NOT re-invent the wheel.
I always build stored queries when I'm using forms that will draw data from linked tables. That way I can do things like impose a specific order of record appearance, which is something you can't do so easily from a table-based form. Even when the query draws every field from the single table on which it is based, I can do sorting and filtration (of a non-dynamic style) in the query before giving the record to the form. And that is (in my experience) easier than always trying to build a dynamic query that, despite BEING dynamic, always does the same thing.