So there’s a few things that the BAQ does for you that you don’t see and if one had to do it in SQL would be a nightmare. For example:
BAQs respect Field Security. Epicor implemented field security at the application level making it easier to manage by security groups. No need for Altering the database schema.
BAQs respect Company and Site security. An SQL author would have to remember to correctly return different results based on the user running the query.
BAQs respect Territory Security. An SQL script would have to limit records based on the territory that the user has access to.
BAQs hide User Defined field details from the author. An SQL programmer has to know to use a view or manually make the linkage.
BAQs hide the details of the PatchFld table. While Epicor doesn’t make any schema changes at the patch level, sometimes they need to add a field. The PatchFld table is a hack to add a field without changing the schema and a BAQ will automagically handle this for you.
I have to claim ignorance here but I wonder about caching too. I’m not sure if BAQs account for data not yet flushed to the database. However, this is a big difference with some web applications and historical database applications many of us are used to. The database is not necessarily the source of truth. 
Even in SAP HANA, where the database is entirely in memory, it’s quite possible that you won’t find the most recent data in the database but have to use SAP methods (or “BAQ”) to get the correct information. I haven’t looked into it to know for sure.
Systems that follow a CQRS model, like Stackoverflow, where the updates and reads are separated cannot directly query a database directly since the most common information is cached.
SQL just works if you know how to work it.
**EDIT: SQL requires intimate knowledge of the database design and most users don’t know it and most developers don’t know they don’t know it.