One counter example:

    $ curl -LO 'https://burntsushi.net/stuff/subtitles2016-sample.en.gz'
    $ gzip -d subtitles2016-sample.en.gz
    $ time rg -c 'Sherlock Holmes' subtitles2016-sample.en
    629

    real    0.099
    user    0.063
    sys     0.035
    maxmem  923 MB
    faults  0
    $ time LC_ALL=C grep -c 'Sherlock Holmes' subtitles2016-sample.en
    629

    real    0.368
    user    0.285
    sys     0.082
    maxmem  25 MB
    faults  0
    $ time rg -c '^\w{42}$' subtitles2016-sample.en
    1

    real    1.195
    user    1.162
    sys     0.031
    maxmem  928 MB
    faults  0
    $ time LC_ALL=en_US.UTF-8 grep -c -E '^\w{42}$' subtitles2016-sample.en
    1

    real    21.261
    user    21.151
    sys     0.088
    maxmem  25 MB
    faults  0

(Yes, ripgrep is matching a Unicode-aware `\w` above, which is why I turned on GNU grep's locale feature. To make it apples-to-apples.)

Now to be fair, you did say "usually." But actually, sometimes, even when functional parity[1] has been achieved (and then some), perf can still be wildly improved.

[1]: ripgrep is not compatible with GNU grep, but there shouldn't be much you can do with grep that you can't do with ripgrep. The main thing would be stuff related to the marriage of locales and regexes, e.g., ripgrep can't do `echo 'pokémon' | LC_ALL=en_US.UTF-8 grep 'pok[[=e=]]mon'`. Conversely, there's oodles that ripgrep can do that GNU grep can't. For example, transparently searching UTF-16. POSIX forbids such wildly popular use cases (e.g., on Windows).