As I said at the beginning of my first post higher up, different companies have different requirements, and there's no one right solution.
But as for the last point, many companies prefer constant integration of work in progress (perhaps with new functionally disabled) for development work that can take multiple weeks, rather than working entirely in a feature branch and introducing a massive change in one go, especially if it's required refactoring work to existing code. On such codebases, my commit frequency would typically be at least a couple of times per week, perhaps a couple a day in some cases.
So, while each commit will have a commit message explaining the change, none of those commits would be a sensible place to try to explain the justification for the work, something which I was already arguing shouldn't be in commit messages at all. The last point was an attempt to show that it makes even less sense to try to replicate the why of the feature requirement in the commit message at all. That is already documented in the ticketing system, the commit message should contain a summary of what changed, to aid a later developer trying to track down a bug.
From your third paragraph, it seems that we largely agree, you just disagree that the information about the ticket a change relates to is important enough for the subject line. If it was a URL link, I'd agree because they are long and messy, but honestly a JIRA reference like [PRJ-123] doesn't use much space and putting it on the subject line seems the best compromise to me, because I consider it mandatory. But if your company prefers a different policy, that's fine too - different companies don't all have to do the same thing.
FWIW, I've also worked in what you call '"hard" foundational software'. In fact, that's exactly where I was first exposed to this policy, recognised it was better than previous systems in previous companies for traceability, and later advocated it in other companies with smaller teams, and also use it myself on my one-man projects.