I don't think it's helpful to single out "corporate developers" as the black sheep that submit all the style violations. Every contributor, paid or hobby, new or long-time, needs to pay attention to the project guidelines equally. Everyone overlooks stuff some time, and it's normal especially for new contributors to not be quite that familiar with everything yet. Its our responsibility as reviewers (especially those of us with +2 rights) to educate them and make sure the rules are followed before a patch can get submitted.
That said, I do agree that we have a lot of potential in making this easier and more consistent for everyone involved. I think the best tool for that is more automated checking... like that recent idea to make Jenkins add the checkpatch result visibly to its Verified+1 message.
I'm not sure if the "where" of the guidelines really makes much of a difference... maybe we should just make them more discoverable either way? Could we put a big orange "please ensure that this patch conforms to the style guidelines at ..." banner in Gerrit somewhere near the submit button?
I also think that our guidelines could use a lot of cleaning up, honestly... it's a big mess right now, and the harder they are to read the easier it gets to accidentally or intentionally ignore them. Right now we have https://www.coreboot.org/Development_Guidelines which includes a lot of stuff duplicated from https://www.coreboot.org/Coding_Style. The latter is almost a direct but not quite copy of the Linux Kernel Style Guide (to the point of still including a bunch of stuff that makes no sense for coreboot, like the net/ and drivers/net/ commenting exception), so it's easy for people to take a quick look, think "oh, it's only a copy of this thing I know already" and miss the subtle differences. I think it might make more sense to cut that page and rewrite Development_Guidelines to say "coreboot code must confirm to the Linux Kernel Style Guide <upstream link> with the following exceptions/additions". And then we also have Documentation/gerrit_guidelines.md in the source which is yet again a different, slightly overlapping set of rules that should probably get merged into the main guide.