There are some clear distinctions between commands and events but there are also some not so clear. I discuss the notion of a command as an interpretation of an event.
Commands are requests to do something, they are named in the imperative tense and capture intent. In CQRS, commands are distinguished from queries because they invoke behaviors therefore causing state changes whereas queries don't. In some frameworks, there is a distinction between commands and events in that one sends commands and publishes events. Commands are sent to a single logical handler whereas events are broadcast to potentially multiple handlers.
Events are characterized as being in the past tense. In addition to naming this imposes the constraint that events can't be rejected - you can't change the past. Furthermore, an event can be regarded as an outcome of a command - a causality relation.
There are perspectives where the distinction blurs. For example, what is the distinction between a command handler and an event handler? (One could argue that a distinction can be that it is appropriate to reply to a command but not to an event, but this is not set in stone). An event handler typically reacts to an event by invoking a command. One could describe this command as the handler's interpretation of the event. This model however can also be applied to command handlers. Every imperative tense command can be regarded as a past tense event, ie AddItemCommand => AddItemRequested. Just like you can't reject an event, you can't reject the fact that a command was issued, you can't reject the fact the there was intent. In this way, every command handler can be regarded an event handler. A conceptual consequence of this is that commands are highly context sensitive and ephemeral - they "exist" only for the duration of an event handling transaction.
The notion of a command as an interpretation of an event can be a helpful metaphor in designing a reactive, decoupled, event-driven system. It may help to prevent coupling more reminiscent of RPC than EDA.
Consider the example of an occasionally connected client. When disconnected, the client may still allow the user to perform certain actions. Once reconnected, the client syncs with the server. This synchronization process can be regarded as an exchange of events. The client tells the server what happened on its end and the server does the same. It doesn't seem right for these disconnected client events to be commands - after all, the server doesn't have the authority to reject them. The server can issue compensating events, but it can't say that they didn't happen. Isn't it possible to consider all systems from this perspective?
In terms of the chain of causality, there always seems to be an event which leads to a command. An AddItemCommand can be triggered by a click of a button. Informally, one could argue that there was some event in the user's mind which lead them to click the button. When events are handled, they invoke commands but this command is very short-lived and context bound - it is owned by the event handler and once a command is sent it effectively becomes an event.