I've been using SQL for more than 40 years. In the 80's and 90's it was embedded SQL in COBOL. I used to dream of a way to remove the burden of having to remember all the table and column names and manage to type them without error, especially when I wasn't the one who built the schema. Then in the early 90's, I discovered Access. I found that I could link to DB2 (IBM's RDBMS offering) on the mainframe and view and update with Access. I was hooked. AND I got a GUI SQL editor to boot. OK, it's not a good editor but for the vast majority of queries, it is good enough. I can point and click and not worry about typos. I can use criteria so the values can be provided at runtime. I save the queries as QueryDefs and I NEVER look at them in SQL view because the editor, changes the formatting to suit itself.
So, unless the SQL is actually dynamic, I use querydefs. There is a trick though. Sometimes I have complex selection criteria and the editor always wants to rearrange it and add a gazillion parentheses. However, I can foil it by switching to SQL view and creating the WHERE clause there. I can format it neatly (I don't bother with the Select clause) and save it. As long as I never switch to QBE view, the editor won't mess with the SQL string. As a back stop, I also keep a table where I can paste the string after I build it so if I lose my mind and switch to QBE view, I can just pull the string out of the table and be back in business.
Dynamic SQL usually only occurs when you have complicated search forms or you build a fancy, custom export process for the user. Otherwise, SQL is static and so QBE is the simplest solution. Remember, no one is going to make you look at the SQL string so you will only be offended by its lack of formatting if you look. Just don't look
One place I always avoid SQL strings is as the RecordSource for forms or reports. I always use Querydefs for those. WHY? Because there is a long standing bug in Access where Access loses the SQL "string" and assumes it to be the name of a querydef so it truncates the SQL. I just had it happen last week. I have no idea what triggers it.