Not a professional game developer, but do write high performance C++ code for a living.
In any non-tiny project, following some good guidelines (like the ones posted) will:
- result in faster development (debugging is a significant part of development time),
- result in a more robust product for a better user experience.
For example, not checking return values can result in either a miserable debugging session if it causes a problem that cascades to somewhere else (learned that the hard way), or a silent crash when the user runs your game in a way that causes some failure that didn't occur in testing.
A difference between game code and other code is that game code has a shorter expected lifetime, but I seriously doubt that is enough of a difference to make those guidelines any more or less useful.
For code that only I see that I plan to throw away after a week or so (say a one-off conversion), sure I'll not worry so much about guidelines.
Having said that, guidelines are a useful set of handrails, not a straightjacket, and you are sometimes doing yourself a disservice by following them slavishly - I routinely break many of them, and which ones are important will depend on your project.
For instance (as @DMGregory points out) in hot loops with a tight time budget (this happens in non-games too!), you don't want to follow guidelines at the expense of performance - for a hot enough loop you do whatever (safely) needs to be done to meet your time requirements. Even in those cases it is sometimes better to start with a guideline conforming version as a base, and an optimized loop should be very well commented so you can see what you did (and why) when you come back to it.
I have been involved in projects in which every guideline must be followed without fail, and projects where guidelines are ignored, and they are both awful.
Having spent more time in those guidelines, they seem pretty good and not over-prescriptive (but looks like they haven't been finished yet), and they give reasons. For instance, rather than the common "thou shalt never use goto" I've seen so often, in "ES.76: Avoid goto" they say why to avoid goto, and when goto is ok. Some of it is stylistic: "Enum.5: Don’t use ALL_CAPS for enumerator". Overall, they are good enough that I'd want to be able to give a good reason for any part of them that I'm not following.