Changing database recovery models: FULL to BULK-LOGGED and vice-versa
Since SQL Server version 2000 better enhancement of three types of recovery models: simple, full and bulk-logged are fetching long-run support for all kinds of database activies. As you know such recovery models offer varying levels of recovery for restoring your databases from your backups, overall if there is a bulk data update then "Bulk-logged" recovery advantages include minimal space requirements for transaction logs and the best performance for bulk operations.
RECOVERY models affect the way handling SQL Server backups & restores, using SP_DBOPTION or ALTER DATABASE statement you have such option of changing the db model from full recovery to bulk-logged recovery and back as needed without interfering with your transaction log backups. As a matter of fact this allows the process to keep the size of that database transaction log in check when doing large bulk-logged transactions. But there is a catch doing such intermittent or frequent switch over of recovery models, main importance is how the transactions are written to your transaction log backup. If there is a bulk-logged transaction in your backup file, you cannot do a point-in-time recovery (by design). So this is where you have to be more careful if chaning recovery model process is persistent, because due to the bulk-logged transaction exists within a transaction log backup, you have to restore the entire transaction log when such RESTORE situation arises.
Out there I have seen it has been advised to change the recovery model to bulk-logged from full recovery mode when running DBCC DBREINDEX statement! IMHO, it is not required to change recovery model for the sake of this DBCC statement and this will have lead to point in time recovery issue for instant switch over methods. Within SQL 2005 reindex procedure involved much of TEMPDB usage that you should be consider about. If you really have the disk free space issues then try to reduce those issues than playing with database configuration.
Further reference on INdexOptimization best practices and also if your databases are not involved in database mirroring then you can switch the recovery models without any issues, but should keep in mind to perform a full backup before and after those bulk load operations to be safer than sorry! Additional read on how recovery model affects the log refer to 190203 & 190692 articles on MSDN.