I've grappled with code style guidelines for years, as many others have on this forum. This includes both fighting style guides I find abhorred, and trying to encourage others to use style guides to rein in their style so it can be more readable as a whole.
The corporation benefits from a common coding standard. There are many important things to consider when developing software for a company, like how we will train new developers to pick up the previous generation's code. When you're writing code, you're not always thinking about this. In fact, many coders choose not to even consider how others might want to approach the code 5 or 10 years after they've gone. A coding style guide is a way for a corporation to provide focus for these 5 and 10 year goals, making it easier for developers to work in the larger scheme of things.
On the other hand, coding style guides are notoriously imperfect, because it is not possible to develop a perfect coding style and write it down. You actually start running into funny corner cases where mathematical proofs start to fail if you try to make it perfect. So we know the coding style guides are imperfect. They may not perfectly focus on what we need 5 to 10 years down the line.
If we "enforced" a coding style, we would be sacrificing value now for value later. This would be called "investment" if we could be confident that we would get a return on our efforts, but any developer who has worked with a poorly written coding style guide can attest that those "readability" gains are paid for dearly by distracting developers away from their code. In my experience, there are only a very small number of cases where enforced coding styles have merit, typically on software for uniquely glacial customers where software may be used for 30 or 40 years!
Instead, I find it most effective to treat a coding style guide as a manifesto: "This is what we believe the best coding style is for our group." It's a bunch of fluid thoughts documented in words. The word "believe" is important: if beliefs change, coding style guides should change with it.
This is where your "strong personal objections" quote comes in. In what I would call a "perfect" world, you write whatever code you feel is best, and you live with the consequences. We often like to overlook the "soft" consequences when we're programming, but in this case they are important. I have no problem with you writing in your own style, if you don't mind me never giving you anything important and long lasting to develop.
Think of the whole system like a golf course. The coding style paves the easy path down the fairway. If you hold yourself to the coding standard, we'll make sure life is as easy as we can. The further you get off into the rough, by using your own coding standards, the more you are going to have to prove your value on the team.
If I come in Monday morning, to find you've spent all weekend solving a problem we've been fretting over for a year, and you did it in your own "special" coding standard, I'm not going to tell you to fix it. I'm going to tell you to go take a shower. If your "special" coding standard is exceptionally "special," I might even suggest an entry level developer "review" the code to spread the knowledge of how your code works and offhandedly mention that if anything looks hard to read, he/she should tidy it up. You provided enough value to the company that weekend that it's worth not even mentioning the egregious coding standards violations you committed.
There are, of course, out of bounds in this golfing metaphor. If I ask you to do some rank and file task, perhaps adding new fields to some form, and you decide to use the opportunity to refactor the entire form-filling code to suit your particular style, using a bunch of shady characters like define macros and some god-awful template meta-programming technique you just learned from stack exchange, you will be asked to go back and fix it. You chose to act, those are the consequences.
(Disclaimer: I've totally written this implementation of
is_base_of to solve a menial task, and earned every bit of hell I got for it from the senior developers. I say it was worth it. I still get a mirthful bubble of laughter every time I look at how that pattern wedges like 7 unrelated parts of the C++ specification together to do something amazing. Take that, you senior developers! That's what you get for forbidding
boost on this particular project!)