Because at the end of the day, SQL it what's being run by the database. For example, in the Showcase on the front page, they have an "Orthogonality" example that demonstrates filtering both before and after an aggregation, which compiles to a WHERE clause and a HAVING clause respectively. WHERE and HAVING have very different impacts on SQL queries, and vastly different performance implications, but the simplification in PRQL obscures that complexity.
At the end of the day, the transpiled langauge will have to either support only a subset of SQL's features, or else be at least as complex as SQL. It cannot support all of SQL's features and yet be less complex, because it is just a wrapper around SQL.
I suppose for the right crowd, possibly people who run queries only once and do not care about performance implications, data integrity, etc., this could be a really useful tool. And in all fairness, they mention exactly that on their homepage:
"PRQL’s focus is analytical queries
PRQL was originally designed to serve the growing need of writing analytical queries, emphasizing data transformations, development speed, and readability. We de-emphasize other SQL features such as inserting data or transactions."
But for developers who need to maintain an application database, I don't foresee this becoming a useful substitute for SQL.