Reality is more nuanced than that. Some private extensions or unratified extensions should really be frowned upon because they risk fragmenting the RISC-V ecosystem. Examples include the completely incompatible version 0.7 of the vector spec and T-head's assorted private extensions.
The H extension is a little less clear cut as it doesn't affect user code (IIUC) and as such the damage is limited to OS kernelS (there's more than Linux out there).
However it's a slippery slope into fragmentation hell and I actually think the current policy is correct and the blame lies with the H committee.
RVV 0.7.1 is not completely incompatible with the current 1.0 draft. The overall structure of code is the same, most instructions and opcodes have not changed at all, especially unmasked operations.
I have demonstrated that at least memcpy() can be be binary compatible between 0.7.1 and the current draft. I will check others soon (once I get a Nezha board, hopefully before the end of the month). Many other things could be made compatible -- most simple code using 16 or 32 bit int or 32 bit FP -- by reverting a single small commit to the spec in June 2020 which tidied up the bit field format of the VTYPE CSR but did not introduce any functionality.
There are things that are incompatible for very good reasons, but there is much that is either compatible now or that is incompatible for inessential reasons.
Reverting the format change in the SEW and LMUL fields, and making 0 for the mask agnostic and tail agnostic bits match the (fixed) settings in 0.7.1 would go a long way towards increasing compatibility, at virtually zero cost.
The H extension is a little less clear cut as it doesn't affect user code (IIUC) and as such the damage is limited to OS kernelS (there's more than Linux out there).
However it's a slippery slope into fragmentation hell and I actually think the current policy is correct and the blame lies with the H committee.
EDIT: language