It depends on whether something runs fast enough. Certain software, such as filesystem drivers in the OS kernel, never is fast enough as there is always someone who wants it to run faster, use less memory, etcetera. Efforts to get it as close to 0 overhead as possible (without killing maintainability) tend to be applauded by the community. Here are some patches I have written against kernel filesystem code in the past few years that were merged because people care about performance:

This patch shaved a minuscule number of cycles off a hot code path, and was accepted on the basis that microbenchmarks showed that it made extremely hot loops run a few times faster:

https://github.com/openzfs/zfs/commit/59493b63c18ea223857066...

This patch eliminated a redundant calculation that used 0.8% of CPU time:

https://github.com/openzfs/zfs/commit/3236c0b891d0a09475bef8...

The impact of the following patch was not measured, but it is believed to have made checksum calculations run several times faster by eliminating unnecessary overhead:

https://github.com/openzfs/zfs/commit/59493b63c18ea223857066...

The reason why the impact was not measured is that the code runs with interrupts disabled, which makes it invisible to kernel profilers. Another way of measuring was needed to quantify the improvement, but everyone agreed that it was a good improvement, so there was no need to evaluate the before/after improvement.

Few people are willing to accept the performance impact of moving their filesystem driver into userland and practically no one wants the performance impact of moving almost everything into userland.