With normal pathfinding you`re looking for a path between two locations, in the case of the realistic AI pathfinding you`re looking for a path between two situations.

Anything which can be represented as a graph, like multiple potential actions leading to certain events, including eventually different sequences of actions leading to the same events, can be processed by graph algorithms.
The actions are the edges, the events are the vertices in the graph. The edges can have a cost, e.g. ammo needed, and health do be lost. From such graph, Dijkstra could find a sequence of actions with minimized cost to cause a certain, final and desired event. A Spanning Tree could help if multiple events must be passed.

Notice, the grid based path finding in games is not the 'normal case' as you say. The normal case is to use graphs, which means we have vertices and nodes, likely with adjacency lists, so a vertex knows all it's edges. But unlike a mesh, there is no need for a spatial representation of this. There is not even a need to say we are in 2D or 3D. So yes, you can and should use those algorithms for many things, as you have just discovered.
What makes the game grid so special is: The adjacency of a vertex (in this case a grid cell), is implicitly given by the grid structure. We do not need to store an adjacency list to find neighboring cells - we can just use simple increment and decrement on the current grid coordinates to find all neighbors.

So this is how you put your ideas to practice: Make a graph data structure, write a new Dijkstra which works on that. Represent your potential moves in a game as such graph, and it should give you some smart decisions.

Everyone knows what A star is.

Well, i don't. How does it work?

Anything which can be represented as a graph, like multiple potential actions leading to certain events, including eventually different sequences of actions leading to the same events, can be processed by graph algorithms.

I guess you can treat it like that too although it looks like a bit of an overkill.

If you have a unit of type Z threatening your base (lets say zerlings), to save your base you need the antidote which is barracks level 2 type 2 (if you`re playing as human). Barracks level two means that it`s a unit produced by the Barracks object (building), it`s a child of Barracks. Type 2 is the firebat, (another barracks level two type is marine). You may know what the antidote is from a list of antidotes loaded by the computer from a file. Another way to know what the antidote is, is to find it by Machine Learning (run all the possible alternatives and see which works best). IMO using a ready to utilize solution that is loaded from a file works best.

If you have firebat units built (trained) you will just use them if you don`t and but you have a barracks building built you will train firebats. If you don`t have a barracks building built (that would be barracks level 1) you need to build it first.

Here is an example of a task that needs to be completed in the Windows shell: copying a file from a location to another location. The end result we`re looking to achieve is always an image. The idea of a file in a given location is basically an image with windows explorer opened at the desired location (the desired folder) with the file in question in it. To get to that image/state you first need an opened windows explorer. The second step is have windows explorer opened at the desired location (which is achieved by navigating to that location within WE). Once the destination location is 'opened' to make the desired file appear there you have to access copy solution/procedure from the memory. The copy solution states that you need to open place where the original file is found, select the desired file, copy the file to the clipboard etc.

Each menu has a number of predefined properties. Finding the path means staking several menus where each menu has properties that match another menu. You build the path out of menus. Two menus combine like a gig saw. It`s like trying to pass an object through the right type of hole ( there are square shaped holes, round holes, triangle shaped holes, not any object fits any hole). There are properties that match and properties that don`t. To find the next menu you iterate through all the menus available and pick the one that is matched with the current menu.

I guess you can treat it like that too although it looks like a bit of an overkill.

It's not overkill. It was just an example to point out graph algorithms are much more general than you would think, if all you ever did was path finding on a grid.
Whenever you have a set of potential moves, and you can connect them by dependencies, consequences, temporally, spatially, or whatever else, then graph algorithms are likely your primary tool to figure out a good strategy of moves.

You literally meant just that in your opening post, but it was one of your loose concepts, not really thinking about how to program it.
Then i tell you: ‘You already have the algorithm to do this, just make it more general which is little work’. And you respond: ‘ugh - sounds overkill’. Sigh.

Read this for a practical problem which should rise in RTS. (And notice that graph algorithms often can not find the ideal solution to a hard problem in reasonable time, so we have to be creative and deal with approximate solutions)
Other related problems are hungarian assignment problem, stable marriage problem, travelling salesman, etc.

I know nothing about RTS, but i guess RTS AI uses graphs for more things than just path finding.
If i would aim for good AI in a game modeling complex economies, or dream about intelligent machines, i would certainly look at this to get working specific 'problem solvers'.