If your system tracks all features/bugs then you likely will have a ticket of some sort. But if your system only tracks bugs (for some reason?) and all new development is a free for all.
Some significant advantages:
- Some VCS/ticket systems allow auto hyperlinks for the ticket number when browsing the commits in the issue tracker (this is super useful, see github, redmine)
- It provides some context for the inevitable "why did Simon do this? Makes no sense!" question
- Often this might be years later...
- Context for changes can take a lot of work multiple years in the future. Having a ticket with an explanation for why the code was changed can be super, super useful
- Helps keep people working on value-add things
- "Oh, I'm going to refactor this.. and this.. and this... and... oh I've not done any value-add work in a week!"
- Can allow searches to find commits related to an issue
The only disadvantage is if your team doesn't really use tickets or a tracking system. Then it'd be harder to find the ticket number. Or if your VCS and issue tracker don't integrate well.
And... you should track all efforts somewhere, so, if that's why you are not using a ticket system for nearly all of your work I'd strongly suggest doing so, regardless of whether you have it included in your commit messages.