Your historical understanding is quite incorrect. A general method for finding solutions to any and all sorts of permutation puzzles was already known long before Erno Rubik ever conceived of his cube. Indeed, anyone with a basic grasp of commutators can derive a complete solution for any such puzzle with just a little bit of trial and error.
After the Rubik's Cube was released internationally in 1980 — and became an overnight sensation in much of the world — interested mathematicians almost immediately began to apply more powerful (and well known) group theoretic tools to it specifically, at least partially motivated by the desire to find more efficient solutions. The first algorithm based on those efforts had already been published by the end of 1980, and was written about in magazines in 1981.
In practice, efficient group theoretic algorithms rely heavily on large computer generated tables enumerating transitions between different families of positions. Finding a solution involves classifying a given position, looking up how to move from it to a more restricted family of positions, and then to a still more restricted family of positions, etc., until the cube is ultimately solved.
If you'd asked any of those interested mathematicians and computer scientists at the time if they thought increases in computing power would allow them to improve their algorithms, they would have said, "Obviously!" If you'd asked any of them if they thought Moore's Law would one day make God's Algorithm a reality, they would have said, "Almost certainly!"
Interestingly, practical implementations of God's Algorithm don't actually use group theory. While they similarly subdivide the Rubik's Cube's configuration space, it's generally not done in a group theoretic way. Depending on which method of subdivision is chosen, tens to thousands of megabytes of tables are calculated, in order to create an "admissible" heuristic for the distance from the target position. (If you later want to target a different position, i.e. other than the traditionally solved cube, you have to recalculate these tables!) IDA* can then be used to find and prove optimal solutions. IDA* itself was first described by Richard Korf in 1985, though it wasn't (publicly) applied to the Rubik's Cube until the late 90's, again by Richard Korf. If I had to guess, the decade-plus gap was simply due to lack of computing power.
I have absolutely no doubt that if you'd asked Richard Korf in 1985 whether IDA* could be applied to the Rubik's Cube, and whether Moore's Law would allow it to be a practical God's Algorithm within his lifetime, he would have said, "Absolutely!"
Incidentally, you're also mistaken about the ease of computing an optimal solution. Even on modern desktops, some positions require hours to weeks of computation (depending on the size of the pre-generated tables available), though a random position typically requires seconds to minutes. "Instant" solvers all use group theoretic methods, aren't provably optimal, and almost never find optimal solutions in practice. (Good instant solvers still often find solutions of 20 or fewer moves, however. 20 is the diameter of the Rubik's Cube's Cayley graph, so that's pretty impressive!)
Anyway, I mean you no disrespect, but, your "sincere belief" and "good high-level look" at chess notwithstanding, you seem to be misinformed as to many basic facts, and to have a number of fundamental misapprehensions that contradict decades of firmly established research and the broad consensus of essentially all subject matter experts. You don't have a reasonable basis for any sort of intuition. In this instance you should do more than merely accept the possibility that you might be wrong. You are wrong, categorically.
The key facts about chess are:
- Its state space is vast enough that Moore's Law will be halted by physics long before brute force becomes viable.
- Its game tree lacks sufficient structure to be meaningfully simplified.
- Which means it can't have an admissible heuristic evaluation function with significantly less entropy than the game tree itself.
- There's an unimaginably vast, practical, and conceptual gulf between finding the shortest path between two given nodes (i.e. solving a Rubik's Cube), and proving that all possible opponent responses lie on paths that can be forced to a particular terminal evaluation (what you need to do to solve Chess.)
With respect to that last bullet, consider the difference between the following two tasks:
- Find the provably shortest sequence of roads leading from your current location to Rome. This is a relatively simple task. It has an obvious admissible heuristic and readily submits to dynamic programming.
- Prove that all roads lead to Rome. This is obviously intractable. There obviously can't be a low-entropy admissible heuristic, as there's absolutely nothing preventing any given road from terminating before it connects with a Romeward network. You just have to examine each and every road.
