compared to forcing people to write complicated closures that might be just as unreadable as * is. ... the spec currently limits * guessing to some very simple cases

If the guesser is limited to simple cases, then the closures it would replace, would be simple also. By the time you get to the point where the closure would give any reasonably competent programmer a problem to understand, the chances of the guesser, guessing correctly are close to nil.

Even the simplest input to the guesser, say: 1,2,3 currently elicits a gnat's genitalia off of 13,000 matches at the OEIS.

Adding a fourth term 4 cuts that to 5,500; a fifth gets you 3,500; a 6th, 2,500; a 7th, 2,000; an 8th 2,000. And you're still close to 1,500 by the time you have specified the first 9 terms.

I didn't keep going to see how many leads you'd have to specify to uniquely identify even this simplest of sequences, but I tried a few others:

1. 1,4,9,16,25 - 125 possibles.
2. 1,2,4,8,16 - 346 possibles.
3. 1,3,5,7,9 - 233 possibles.
4. 2,4,6,8,10 - 213 possibles.
5. 1,10,100,1000 - 36 possibles.

It's frankly hard to see the win from having a "simple" guesser. And hard to see the possibility of something more accurate.

Especially when it would be so cheap and simple to provide the top ten or 100 most common sequences named as built-ins, or in a core module.