Chess is a vastly simpler proposition though. The moves the player can make are limited and discrete. The moves the opponent can make are also limited and discrete. At the start of a chess game, for example, there are twenty available moves for White (eight pawns can each move one or two spaces, two knights can each go to two positions). For each of these moves the opponent can also make twenty moves, so to look ahead one turn requires 400 separate evaluations. The second turn is a lot more complex; depending on which pawns moved you might be able to shift any of the other pieces. Depending on how the opponent moved there might even be a capture. Still, we're talking about a few billion moves to be evaluated after a few moves, and with a bit of alpha-beta pruning (practical when "score" is reasonably well defined, for example by assigning values to pieces) this is quite manageable on a modern PC.
Running a simulation on a transport aircraft using fixed control inputs and in perfectly known conditions is practical. Obviously you'd have to make some sacrifices in aerodynamic modelling to have it done by an aviation-grade computer (not exactly the latest and greatest desktop hardware) much, much faster than realtime (there's not much point if at any time you can only look a few seconds ahead) but I can see that being possible.
Then you start throwing in variables. What happens if we apply 5% more thrust? What happens if we apply 10% more? Or 15%? Or maybe 14.3726% on the left engine but 1.3978% on the right since that might be a practical way to deal with a rudder malfunction? Or should we apply 5% left aileron? Or 5% right rudder? Or drop the gear?
What if there's a bit of wind shear? Maybe some wake turbulence? Maybe the C-17 that's about to taxi onto our runway will realise what's going on, apply reverse thrust, and get out of the way. Or maybe he'll stop, so that just staying a bit to one side provides sufficient safety margin. Or maybe he'll keep on coming, in which case absolutely any response that involves continuing this landing is going to cause a disaster. Of course, for the first option the computer has to be able to recognise that (a) the plane is a C-17, and (b) C-17s can to taxi backwards on reverse thrust. And if it's listening on the radio it might be able to hear ATC telling the C-17 to stop, and the C-17 pilot confirming (or not).
So now instead of running one simulation to see what will happen, the computer is running thousands or millions of simulations just for the next millisecond. And for each of those simulations, thousands or millions for the next millisecond (so now we're looking at millions to trillions). By the time you're looking maybe 30 seconds ahead (which is probably about the minimum you could expect) you're asking for a *lot* of simulations - and of course because these simulations are covering the dynamics of a large aircraft each one is pretty complex!
Plus, of course, you need big sanity-checks. If someone's gone and parked a plane on the runway you were about to land on, then the best strategy for the next 30 seconds may well be to cut power, lower flaps, lower gear, and raise the nose. All of these will reduce the speed, and therefore prevent a crash within the 30-second simulation time. What the simulation does not know (because it only looks 30 seconds ahead) is that at 31 seconds the plane will stall and crash, and the burning wreckage will slide into the fully-fuelled plane sitting on the runway. You can force the computer to only accept "nice" solutions (eg. where the plane finishes well above stall speed, well below VNE, within 30 degrees of level in both axes, etc) but then that may cut out beneficial solutions that a human pilot could find (eg. coming very close to a stall in order to pull up fast enough). The other effect of the 30-second look-ahead time is that the computer won't even start to think about the guy sitting on the runway until it's 30 seconds in the future; a human might have seen that sveral minutes ago.
The first part of this plan, controlling the plane itself, is essentially heading for a field known as "optimal control" - how do you perform control in the absolute best way to achieve the goal. One way, as you've described, is to brute-force every possible action and pick the best. The downside, of course, is that this tends to take many times the age of the universe on any conventional computer that can be constructed within the universe. The fact that there's a field of study rather than a single "optimal control equation" indicates that nobody's actually solved optimal control for any but the most trivial cases. We do have numerical methods that can produce a reasonable approximation for more complex systems, but a plane is a very complex system which will need a very large amount of careful analysis.
Add to that the outside factors. What are other planes doing? What is the air around the plane doing? Can ATC deal with your crazy plan? What happens if your plane suffers a mechanical failure and so the best plan you had no longer works?
If you can assign numbers to the probability and impact of every possible event, and then spend a long time crunching numbers, you can undoubtedly come up with a single best course of action. By the time this has occurred it's likely that the human race will have become extinct - and that's a very big "if" on assigning the numbers.
Or you can just go with the existing solution, where if the problem is one that the computer knows about then it just implements a solution, and otherwise it hands over to a human. The computer already knows about most of the reasonably common problems, and handles them so well that nobody even notices. Humans are good at spotting future problems well in advance by collating extra information; if there's someone entering the runway that you're about to land on, you'll be recalling what they and ATC have been saying to determine whether it's a risk or not.
Of course, there's still a class of problems that can't be seen coming but do require an instant response, like the 737 rudder PCU malfunctions. We don't have a good solution to this, but I'm not sure that a simulation would help at all. After all, how can you simulate a malfunction when you don't know what the malfunction is?