It's a guideline, the maintainers won't collectively explode if generated but unmarked code happens to pass review.

The problem with "they can just have the AI fix what's wrong" is explained a bit more in the contribution policy itself - https://godotengine.org/article/contribution-policy-2026/ - nice-to-have features often require design decisions which aren't obvious to outside contributors, but which can create a lot of work for maintainers, especially in game engines where backwards compatibility is a must.

A good example is their ongoing effort to restore C# support to web builds - https://github.com/godotengine/godot/pull/106125 - in Godot 3.x .NET integration was done through Mono, so web games could just bundle the Mono interpreter, but for 4.x which uses mainline .NET, the original plan of instead building WASM bundles (https://godotengine.org/article/platform-state-in-csharp-for...) was blocked by .NET WASM bundles not supporting dynamic linking, not by Godot itself.

The modal person asking "When is C# going to be supported for web games?" or prompting a fix likely won't know to ask "Does my fix need SharedArrayBuffer support?" and "Does my fix rely on patching the .NET runtime?", or why those questions matter, and will get frustrated when the fix that works on their machine then can't be merged into the main project.