Joel and I had a lot of fun doing this video for TechEd Online about the state of SharePoint reporting.

 SharePoint Reporting—What's Up? 

Key Points about SharePoint 2007 reporting.

• Project and team based site collection administrators will find out of the box reporting adequate in most situations.
• Search administrators may be surprised by the out of the box search reporting. A. It exists. B. It has some good stuff.
• Portal administrators who are used to very robust metrics may not find the droids they are looking for and may want to create or purchase something.
• Farm administrators won't find anything interesting out of the box and will need to create or purchase something to get the info they need.
• For farm administrators, there's the MSIT reporting framework available on codeplex. http://blogs.technet.com/corybu/archive/2007/10/09/msit-sharepoint-reporting-framework-2-0-released.aspx
• Quest Software has a capacity management tool with some rich reports. http://www.quest.com/capacity-manager-for-sharepoint/
• Quest also has the Site Administrator for SharePoint which in addition to it's administrative capabilities provides lots of awesome reports. http://www.quest.com/site-administrator-for-sharepoint/
• Nintex has released its Nintex Reporting 2008 suite which contains some informative and downright eye-pleasing reports targeted at specific audiences. http://www.nintex.com/NProducts/Reporting.aspx 
• The new kid on the block (at least new to SharePoint) is Idera with their Point Admin Toolset (beta). (Can we work on that name?) http://www.idera.com/Products/SharePointToolset/Default.aspx 
• Others? Let me know and I will check you out and update this post.

If you want to roll your own reporting solution here are some things to keep in mind:

• SharePoint parses the IIS logs and rolls up the information into its own logs. That information is then stored in the content database.
• SharePoint won't report anything unless A. IIS is logging and B. Usage analysis is enabled and has enough time to process the logs.
• Search reporting must be enabled in the SSP settings.
• It's best not to touch the SharePoint databases directly. Modification is a huge no-no and will result in loss of support.
• It may be OK to read from the database in certain situations. Performing one time queries during off hours should be OK. Building a reporting solution that rolls information into a separate warehouse may also be OK to if done right; however, keep in mind that queries can affect your availability, performance, and the underlying schema may change at any time without warning. MSFT in no way supports direct database reads or writes. If you are not a SQL guru who can design lightweight queries stay out of the database!
• The content database contains some accessible information on storage, bandwidth, and discussion usage and some info on hits and visits.
• The content database also contains some rich information on each web, but this information is stored in binary form and there's no information available on how to read it. The best way to access that information is through the published APIs. Check out the SDK for more information. http://msdn.microsoft.com/en-us/library/ms441339.aspx
• Farm admins will find the data available through the OM very useful, but keep in mind that enumerating this information on a per site basis across a large farm will take a long time and may impact performance if done poorly.
• You can parse the IIS logs directly if needed. Log parser 2.2 rocks! http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en
• It's not always easy to determine what users are doing from the IIS logs. Many operations are not logged in a meaningful way.

In summary, SharePoint 2007 out of the box reporting is big improvement over 2003. Portal and farm administrators may want more info and should look into third party solutions or rolling their own solution; however, when rolling your own be sure to do in a supportable way that doesn't impact farm performance.