Windows Server (Standard and Datacenter editions) licenses include permissions to run unlimited windows containers on top of them. So you would only need to pay for the licenses of your hosts.
I wouldn't call that a caveat so much as SOP for Microsoft licensing. A Windows license does not entitle you to run unlimited Windows VMs on top unless you pay for the more expensive edition.
The "hack" of buying a small number of super beefy servers to save on licensing costs was plugged looooong ago.
Also, the ticket and the commits can provide answers to the same questions without being redundant. The answers are just at a different level of abstraction and for different readers. Tickets usually describe product-level decisions, while commits describe implementation-specific details. E.g. a ticket may discuss alternative user flows, while a related commit explains why a specific algorithm, module, or default configuration value was used.
Tying the ticketing system and the repository together is a good idea and definitely worth implementing, but there's a fine balance in deciding what context should be kept in the ticket and what in the code repository. If you put too much into to the ticket and too little into the commits, then git blame loses it's value, for example.
Thinking that providing additional context for commits is a waste of time is short-sighted. Yes, it requires more time and effort in the short-term (i.e. for creating the commit), but if it's a complex, long-lived project, then that extra effort will save a lot of time in the long run.
Sometimes the extra time and effort is already made up for in the review process, which without proper context could drag out and cause a lot of back and forth. Sometimes it might save somebody hours and days of investigation time. This is not to mention the benefits that both the author and the readers of the commit get by better understanding both the problem and the solution.
People are bad at finding out what is important and what is not. Most of the time I have to cut through not relevant stuff that others thought would be important for fixing some issue. Lot more than some insightful commit saved my day, but maybe that is just my environment.
Anyway good luck fixing anything trusting commit messages from long time ago. Code is truth and if you won't investigate you still don't know how it works.
Where did you find the 7 character suggestion? 7 used to be the default suggestion, but the problem of collisions has been acknowledged and dealt with by the git project. Linus himself authored the change that made the abbreviated revision length vary based on the size of the repository: https://github.com/git/git/commit/e6c587c733b4634030b353f402.... Also, the command for creating references to other commits which comes from the git project and is linked to in the article also uses automatic abbreviation length.
