There are a number of companies out there that utilize SQL transaction log backups for their SharePoint solution. This of course is fine and supported by Microsoft, but if there is a complete disaster then the SharePoint administrator will have to piece everything back together. My recommendation is to run the SharePoint full backup option in conjunction with the SQL Transaction log backups.
SharePoint backup / restore (either through the central administration web site or using STSADM utility) will put the farm back together in case of a diaster. SharePoint restore from a SharePoint backup will require the administrator to run through the configuration wizard to build out a new central administration. Once central administration is available, SharePoint restore can run to put all the pieces back together. The SharePoint restore will build out all the IIS virtual server, application pools, web applications, shared service provider, content indexes, and all the links in between.
Once everything is pieced back together SQL backups and be restored over the existing databases that were restored from the SharePoint restore process. Plus the transactions logs can be replayed up to the point of the last transaction log backup.
Now I know your going to say that it sucks because you have to backup in 2 places. Yes this is true, but you only really have to run the SharePoint backup when there is a change to the farm. Changes would included adding a new web application, shared service provider, etc. Also keep in mind that if you will want to backup any changes to the IIS virtual server in case there was host headers and SSL on the site. Plus you will want to make sure you have a backup of any custom solutions and such.