The problem is, you need DB engine to see the 'whole' query to do some optimizations. For example if you do JOINs in SQL as for-loops over the tables inside your application, then DB engine wouldn't be able to use indexes to optimize them.
That's why a separate fully-analyzable language is needed. FLWOR is a nice example because it's functional and fully reference-transparent. So optimization engine can backtrack through definitions and get the complete picture of what's happening. And then use tried-and-true join optimizations.