> If one just makes it faster without major benefits that patch is likely to be rejected
IF the project were overwhelmed with incoming patches, then I would agree that there's probably higher priority changes than optimizing 'yes'.
But I'm almost certain the GNU project is not being overwhelmed with changes to the core utilities. Everything else being equal (code quality, readability, test coverage, etc.) there's really no reason to reject a patch that demonstrably improves the project, even in some silly way like making 'yes' really fast.
No, but there is review and approval of patches (also the most frequent contributors know where the project is going and there is bug tracking)
If one just makes it faster without major benefits that patch is likely to be rejected