My guess is if you are asking a question like this, you probably having gone much past looking at some of the out-of-the-box reports such as simple page views. If that's all you are doing then you're vastly missing the point and power of Web Analytics. Web analytics in general (not just GA) is about looking at trends in data, over time. And the data itself is acquired by following certain rules and behaviors, both pre-defined and user-defined.
Much of the data for reports cannot be easily grabbed from a direct database query, because the data is based on abstracts such as "xyz over time" and aggregated data. For instance, the concept of "scope" for dimensions and metrics, where a variable and/or value will report data about single page view / events, or over the course of a visit (session) or even over a user defined amount of time (like "make this last a month" or "make this last until some event occurs," like a specific variable or variable type being popped).
Because most of reporting involves higher level concepts of data retrieval, the database is abstracted away, and a "framework" is put in place (the report interface) to help you build reports showing the trended data. Even if you are a database expert, it would take way too much time and effort to try and extract the data manually for virtually everything except the most basic data like page views. And basic data like that is not very actionable.
Look at campaign tracking as an example. It all starts with a single var=value. When a user clicks on a link and goes to a page with that var=value in the url, the tracking code grabs that value and starts attributing not only the data about the page (the url, time, type of browser, list goes on and on) but also all the other data collected from custom coding. Then there are other settings you can apply to it, like attaching a cost-per-click or some weighted measure, attributing success towards a goal or event, etc...based on other rules (first vs. last click attribution, etc...). The list of stuff coming into play and what is considered goes on and on and on. Go ahead and try to make those database query strings yourself. Now wash, rinse and repeat because that was just one campaign code. I've had clients with thousands of campaign codes, with many more being added every day. Oh, and also on top of that, tweaking or making altogether new queries based on how you want the actual report to show the data. Cross-referencing and breaking down by xyz. Looking at funnels and scenarios based on that data. And that's just for campaigns, one thing out of many things.
So to make a long story short, think of a report interface as a framework for databases, with predefined queries you can tweak, to make people's reporting efforts significantly easier, especially since most people aren't database experts.
