Right, by "very hard to beat" I didn't mean to imply it was somehow impossible.
Looking at the whole benchmark that that page links to, the difference is within a few percent for the actual searching, but it is also the only software in the author's own benchmark that is even close. The other software that was mentioned in the comment above is some 5x worse.
Nobody is going to change the standard grep for performance reasons.
It really depends on what you're searching. In some types of searches, GNU grep can get very very slow. The page you were linked to includes some benchmarks for that. In particular, cases where you're searching large amounts of non-ASCII (but UTF-8) text. There are some benchmarks for that case here: https://blog.burntsushi.net/ripgrep/ specifically: https://blog.burntsushi.net/ripgrep/#subtitles-no-literal
Also, it's probably not about "feature parity" per se, but standardization. In terms of feature parity, there is very little that grep can do that, say, ripgrep cannot. But there is quite a bit that ripgrep can do that grep cannot do, mostly by design.
"replacing" grep with ripgrep has at least a dual meaning, and it is the source of unending miscommunication. In the one sense, I know plenty of people that have replaced grep with ripgrep (or whatever) in daily usage. This is a perfectly valid thing to do. In another sense, nobody is going to replace grep with ripgrep in a distribution because they almost certainly do not want to stop being POSIX compatible. That is, asking to "just replace" grep with ripgrep is equivalent to asking distributors to stop being POSIX compatible in exchange for some other feature that ripgrep provides. That question is a non-starter, but a lot of people either don't realize that or are confusing what it means to "replace" something.
It "could" in the sense that it's of course technically possible. But it's a _ton_ of work, and it's not clear to me that it would actually be beneficial. GNU grep is doing just fine as far as I can tell at being a POSIX compatible grep.
ripgrep is split into libraries, so if someone wanted this, they could just go do it themselves. :-) It would actually be pretty easy to get something that smells like POSIX. But the details make up a very long tail, and some of those tasks are fairly significant (supporting BRE syntax, supporting POSIX-style alternations, supporting POSIX locales).
Looking at the whole benchmark that that page links to, the difference is within a few percent for the actual searching, but it is also the only software in the author's own benchmark that is even close. The other software that was mentioned in the comment above is some 5x worse.
Nobody is going to change the standard grep for performance reasons.