Otherwise we risk getting into a "king in the high castle" situation where the developers do primarily what they want, and they very rarely try to communicate with normal users.
It is double-edged sword: if there are many different clients, then some bug may be present in one client, but not the other. And then, there is a risk of forking, if some mining pools will run one version, and different mining pools will run something else.
A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.
I know, most developers don't like their software forked, but I have real technical reasons in this case.
It is important to stick to a single version during early stages, but now, I guess the environment is mature enough, that we can work with multiple clients.
But in general, Bitcoin Knots is very similar to Bitcoin Core. There are some minor changes here and there, but it is not something rewritten from scratch, and implemented in a completely different way, than Bitcoin Core. Which means, that many fixes, and code changes, are used by both clients, and they share most of the source code.
If I recall correctly once he even advocated for lowering the block size.
If transaction batching would be widely deployed, then it could be done. And also, signet blocks were already reduced from 4 MB witness into 1 MB witness, just to test smaller blocks, and build fee pressure, without the need to artificially make more transactions.
Also, fortunately, block size decrease can be done without any fork, all that is needed, is just convincing enough mining pools to do that.