Neither of those seem like compelling reasons, though. If the code isn't good enough, you are better incentivizing the team to improve the tool's generated code, than you are increasing the drift between what the tool generates and what is used.

Optimization can almost make sense, but maintaining a patch process is almost certainly the superior way to go. If only because it supports staying current on the generated code.

There's also the reason of not wanting to generate all the code every single time someone new retrieves the repo or needs to revert back to a previous commit.

This reason doesn't make sense. Again, do you checkin the bytecode of your java? I'd expect you, instead, to recompile the java every time you do a build.

Now, I would expect you to have an artifact repository. To that end, you would be able to easily get the generated sources. But, they would decidedly not be in the source repository.

I don't feel the bytecode comparison makes sense, because the generated code is human readable, bytecode is (to almost all intents and purposes) not.

We feel that code generation is something one does explicitly while modelling, not something done every time you build.

Completely our thinking too. Code generation should not be a build or run time dependency.

Our tool also allows developers to review proposed code changes before choosing to commit them to disk.

Code generation is something you choose to do explicitly as you model.