Hi Vik - guru? (blush), no I don't think so.
The log file is always used by SQL server, no matter what database model you use. It's nothing to do with SIMS or any other app, it's the way the SQL server operates.
Any change made by SIMS, for instance, is first written to the log file by the server. This is so that in the event of the cleaner pulling the socket out of the wall, when the SQL server starts up it will be able to check for uncommitted transaction stored in the log file. It scans through these and commits any un-committed logs into the database.)
So, no matter what model of database you use, the log file is an integral part of the database system.
There's some confusion over how the log file is 'used'. It's always used by SQL server, it needs it to maintain a consistent state. But in the case of backups, not so.
In the case of a 'full' backup model, you can restore the database to a point in time by restoring the database then restoring all or some of the transactions in the log file, to any point in time. This is the most flexible system, but requires planning.
In the case of the 'simple' database model, the log file is not (and cannot) to used as part of the restore - it is only used by the SQL server to maintain consistency and to recover its state in the event of a crash or power failure. The simple model only permits you restore a whole backup, any changes made after the last backup will be lost.
Next, why does the log file get bigger? When the SQL server 'knows' that the database has been backed up, it can be sure that the items in the log file before that backup are not needed. After all, we have a backup of that database at that point. The log file is truncated, which means that the portion of disk previously used by the old transaction items can be re-used. A bit like a tape-loop. All being well, and backups running regularly, the log file doesn't grow; it is reused.
If backups go wrong, the SQL server is unable to truncate the log file is it cannot guarantee that the data can be recovered - we haven't backed up the database, so it must keep the logs in case we need to commit the logs into a restored database to bring it up to date. Of course, the 'tape loop' concept fails as we run out of space, so it must extend the physical size of the file, hence the increase in log size.
Be aware that truncating the log is not the same as shrinking the log. Truncating the log makes virtual markers in the log indicating that sections of the log file can be re-used. This doesn't resize the file. Shrinking the file actually reduces the physical space the file takes up by re-organising the log file and throwing away unused space. Unless something crazy has happened (as in @SHimmer45 's case) there's no need to bother shrinking the log file.