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).
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.