This change reduces a lot the amount of automation one can achieve in its deployment, and requires more manual interventions and human time.
This leads to increased costs for maintaining a flatpak package.
As well for rejecting the flathub.json setting, instead of having that configurable by the package maintainer, you will instead have to process issues on github. This again will increase your costs in human time for maintaining flathub, and introduce boring tasks which will reduce your motivation.
I don’t understand what problem your are trying to fix with this change.
No one cares if the package’s history is full of trials and error. This is not a bad thing to have history and I don’t think that so many people read the build script.
Even if a user makes a pull request it does still run the tests on the buildbot, and actually it’ll run them twice: once for the PR and once after the merge, which will lead to increased costs for your infrastructure.