The Intent section for the Command pattern in the Go4 book reads:
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
Let's break some of that down, and look at it in context of game programming.
The Ability to Parameterize the Invoking Code
This allows you to dynamically configure the thing that invokes the command with an action to execute. This can also be achieved with callbacks. Command objects can serve as on OO replacement for callbacks in a language that doesn't support them in a way that you need (e.g., no support for higher-order functions, or no support for closures); but if you need to access or manipulate the state associated with the command later, or to support more complex interface then just Execute(), having a Command class can help.
In the book, the pattern in introduced in the context of developing a framework for application menus, where a menu item can be configured by a Command. The important bit is that the menu item has no idea what it does or what the target object is - it has no understanding of the operation it executes, it just knows that something should happen when it's clicked.
You can vary this basic structure; for example, the receiver my be referenced indirectly, via an ID of some kind (and fetched by some other component).
In games, and specifically in game AI, one rather similar scenario is when you want to support scripting - a command can encapsulate a user-provided script (and maybe carry some metadata along, and possibly a reference to the scripting engine). Here, the calling code knows when and under what circumstances to execute a script, but has no idea what to do and which entities to affect. (Of course, there are other ways to do it).
This promotes separation of concerns between different systems involved (AI, Scripting).
But also, consider something less exotic. Keybindings. There could be multiple keys (or multiple triggers on different input devices) that invoke the same action, or actions can be context-dependent (same key does a different thing in different situations). Furthermore, the player can change these at any time. One way to handle this is to have a set of command objects that you can just plug into and out of the system that handles input, associating them with various triggers dynamically.
The Ability to Queue Requests
Once you have this infrastructure in place to map inputs to commands, you can leverage it in your AI system to control NPCs.
Now, you said:
Usually when programming AI you want the instructions to be executed instantly
Well, they don't have to be executed right at the moment the decisions are made - just within the current cycle in the game loop. Besides, if the game is using the ECS pattern, a command stream approach may be a good fit. Also, some games run their AI engines at a different update rate then the renderer and the rest of the game, and queuing AI output as commands may be a good way to approach this.
Support for Logging
This can mean literally logging, but let's think beyond that. A log is a recorded stream of events. That can potentially be (when constructed with some care), played back. Replay & demo support out of the box! Add in some timing metadata, and with some effort this can also support things like the time rewind mechanic, where the player can rewind time (up to a certain point) to try the same scenario again (something along the lines of what's possible in Braid, or in GRID 2).
The ability to support undo/redo is pretty self explanatory, so I won't go into it.
Another interesting thing you can do is combine this with the Composite pattern, which then enables you to have composite commands - which are made of subcommands. This may simply be treated as a convenience for you as a developer, but this could also provide support for building editors where users can build these composite commands in a GUI, or even enable you to incorporate this into gameplay, where the player can could build custom behaviors as a part of some mechanic - and have the game remember them (since you can serialize and deserialize commands, including composite commands).
Another benefit of treating commands as objects or data is that you can flexibly execute some of them in parallel (if the tasks are parallelizable), which may improve performance.