Is there any definitive reason not to check .aspx designer files into TFS source control

Is there any definitive reason not to check .aspx designer files into TFS
source control

There've been a lot of general StackOverflow questions about checking
auto-generated files into source control, and specifically the pros and
cons of checking in .aspx designer files. My question is whether there any
definitive technical reason anyone knows of that designer files should not
be committed to source control, that would create definite issues that
outweigh the advantages of committing? My current thinking is that
designer files should be in source control for the following reasons:
Designer files aren't always reliably re-generated. It's common for a
control definition to go missing, and this can waste time when identifying
the cause of a failed build, and they can be tricky to re-generate, so
checking the files in facilitates manual recovery of lost control
definitions and highlights where a breaking change to the designer file
has occurred
TFS when correctly configured, should always check out or mark for an
'add' a designer file that's been auto-modified or generated, meaning that
when a solution is checked in, any changes to the generated file will be
included by default
Developers should always be reviewing the files that are being committed,
so in theory should be safely committing any designer files that have
changed
In the case of needing to merge changes to these designer files that have
been made by other developers, this is also a routine operation in a
collaborative environment that it should be possible to do safely as part
of any well-disciplined source control process
So, to my mind, there's a good argument for always committing designer
files - any compelling reason that this in general should not be done?