Backing up with SQL Server is a good scenario if you know what the limitations are. Essentially, this only works fine with normal content databases.
Backing up the configuration database is possible, but it's not supported to restore it. In case of a disaster, you'll have to build a new farm. This means that detailed documentation is essential. When you have your servers up and running, just create a new web application and attach the restored content databases to it. Make sure you have the exact same version of SharePoint installed too.
You already backup the 12 hive, the GAC and the wss directories in the inetpub folders, so that's a good thing. I usually restore them to another folder and then pick and choose what to actually restore. With proper change management, it should be possible to restore all customizations. Of course you only allow them as solution packages so that's an easy one :-) When you restore the wss directories, you can scan the web.config files to make sure you have all other dependencies installed again.
If you reschedule your SQL backups to run daily full backups, and some incremental log backups you should be covered. If your content databases have a reasonable size (=< 100 GB) it should be relatively easy to restore them when needed. When you use SQL 2008, you'll have the possibility to use backup compression which can make a dramatic difference in storage space used!
To further reduce space used by your backups, consider not backing up your search index and databases. If you have good documentation, you can have this rebuild. Of course this depends on the size of stuff you want to index.
