There could be valid reasons to always run with innodb_force_recovery=1, which causes some corruption to be ignored by crash recovery.

Up to innodb_force_recovery=2, everything should work more or less normally; only some background writes (such as purge) are disabled. Even innodb_force_recovery=3 could be OK, but any recovered transactions would not be rolled back. While the locks held by such transactions could block normal DML or DDL operations, I think that it should work with Mariabackup, which is only relying on MDL, not on InnoDB locks.

With innodb_force_recovery=4 or 5 (before MDEV-19514 in 10.5), corruption may be actively introduced in the system, by the change buffer merge being skipped. This should not interfere with backup.

The setting innodb_force_recovery=5 causes InnoDB to run all transactions as READ UNCOMMITTED, and it should block writes from applications.

I agree that with the setting innodb_force_recovery=6, backup should refuse to work. With other settings, it could be worth a warning. Perhaps we would want to introduce an option that forces the backup to be taken even though the parameter is set?