Python 3, 131 bytes / 0.9464 = 138.41927303465764

-34 bytes thanks to Nicola Sap

-2 bytes thanks to ShadowRanger

lambda x:max((''.join(chr(97+(ord(u)-97+i)%26)*u.isalpha()for u in x)for i in range(26)),key=lambda x:sum(map(x.count,'etoanirs')))

This answer is a lot worse than other answers because there's not a convenient way in Python to count multiple substrings, so I have to use a for loop to do so.

The lambda l enumerates the offsets, and then judges the string by the occurences of etoanirs in the code, and then returns the decrypted string.

Tell me if you can improve this.

Try it online!

Vyxal, 10 bytes, 99.9%, score 10.01

‡ka*݇øDL∵

Try it Online!

Based on Jonathan Allan's idea of compressing the strings, this takes the rotation that's compressed the best in Vyxal's dictionary. Unlike Jelly, Vyxal has a string compression function øD built into the language.

‡---İ      # Collect all the unique results of
 ka*       # Ring translating the input by the lowercase alphabet
     ‡---∵ # Take the minimum by
      øDL  # Length of string when compressed with Vyxal's dictionary

For the curious, the 10 failed testcases are:

got 'vg gb enmr vg, ohg' expected 'it to raze it, but'
got 'qh c "agu qt pq"' expected 'of a "yes or no"'
got 'rpe xh bti pcs id' expected 'cap is met and to'
got 'sio oj ni vy u' expected 'you up to be a'
got 'ct gaiuuzwbu obr dwfo qm' expected 'of smuggling and pira cy'
got 'ihy iz nby gyh ch nby' expected 'one of the men in the'
got 'dnswpa, dnswfm, dnsxfnv, afek, vwfek, vgpens' expected 'schlep, schlub, schmuck, putz, klutz, kvetch'
got "w'a cb am hift wt" expected "i'm on my turf if"
got "h aoplm pz ohyzo, ildhyl" expected "a thief is harsh, beware"
got "aol hesl vm aol dolls" expected "the axle of the wheel"

Most of these are a consequence of a) vyxal not compressing two-letter words b) vyxal compressing a lot of common three-letter sequences.

Jelly, 19 bytes, \$94.65\%\$; score \$=\frac{10000\times 19}{9415}\approx 20.18\$

ØaṙJ,€¤y€ċⱮ“Ẉ²»S$ÞṪ

A monadic Link that accepts the encrypted text and yields its guess.

Try it online!

How?

Same approach as Neil's answer, except that:

1. the translation order is different
2. it uses antiheroes to (a) add the two next most common letters, r and h, and (b) double the importance of e over the others.

Here is some ungolfed Python code that gives 100% accuracy for the test battery (only first 500 shown due to time limit on TIO)

It works by finding the minimal length optimal compression of the \$26\$ transforms using Jelly's dictionary (a Linux words file from Dennis' computer, split into short and long words). It has only been tweaked beyond looking for the shortest compressed string to avoid nine false results by disallowing eleven strings:

" yt"
" qi"
" cn"
" xc"
" noy"
" c'"
" kc"
" x "
" paa"
" ej "
" wb"

JavaScript (ES6), 80 bytes / 0.9468 ≈ 84.50

Improved ^(*) by taking inspiration from Neil's approach.

Expects an array of ASCII codes.

a=>(g=b=>i--?g(a.map(c=>n+=8920258>>(c-i)%26&c>>6,n=0)|n>b?(o=i,n):b):o)(0,i=26)

Try it online! (only the first 100 entries)

_{(*) Compared to my initial version which was based on 2-character patterns}

JavaScript (Node.js), 48 bytes / 0.3269 ≈ 146.83

This is a short (and fast) one, showing that taking only the first two characters into account is enough to reach a success rate above 30%.

Expects an array of ASCII codes.

([x,y])=>(x+Buffer("BCFG?M;")[(y-x+78)%26%7])%26

Try it online! (only the first 100 entries)

65 bytes / 0.4683 ≈ 138.80

A better success rate and overall better score can be achieved with a longer lookup string. But this somewhat defeats the purpose of the above version, which was to have the smallest possible valid code.

([x,y])=>(x+Buffer("G8F:?M=4?6M?9;BF=G?4;BC49G")[(y-x+78)%26])%26

Try it online!

Charcoal, 31 bytes, 93.66%, score 33.1

≔ＥβΣＥθ∧№βλ№etaonis§β⁻⌕βλκηＩ⌕η⌈η

Attempt This Online! Link is to verbose version of code. Outputs the shift N. Explanation: Finds the lowest N where the "cleartext" contains as many of the letters etaonis as possible. Removing a letter will reduce the accuracy to 88.58% while adding a letter will only increase the accuracy to 94.65% either way resulting in a slightly higher score. Even switching to calculating M reduces the accuracy to 93.42%!

There is actually a way to run a whole test suite from the command line but sadly I've never tried it myself, so for testing I actually wrote a longer version which reads in all 10,000 strings in turn.

My best accuracy using a variation of this method is 99.17% achieved by adding negative weighting for the letters xxzzjjkvp (yes that's double weighting for xzj), plus disallowing all qs not followed by a u.