My few cents:
Code style serves many masters. Part of the code's intent is clarity for the person who is writing it; part of the intent is clarity for the people who will read it in the future; part of it is mechanical (e.g. matching indentation style so others don't have problems); and part is purely an expression of shared aesthetic values.
Often, strict compliance to a set of rules makes it harder to achieve some of these goals. I have idiosyncratic formatting in several places, allowing the small deviation from the norm to serve the goal of clarity while at the same time having a consistent style where these issues do not matter.
+1 at having a style guide that makes recommendations.
+1 at having tools that make it the default to apply these recommendations. For example: a guide that shall serve as a style guide for Xcode completions, the formatting of Swift fixits as they are presented in error messages or applied in Xcode, served via LSP as suggestions etc.
A mild rebuke at requiring strict, 100% adherence to a maximalist style that doesn't allow local clarity deviations.
±0 to requiring strict, 100% adherence to a well-thought-out set of principles that doesn't hinder the above.