It can be easy to fall into the habit of conflating the two, as they both accept messages from a Message broker from outside the bounded context of the domain. But their purpose, while similar, is fundamentally different:
Events represent something that has already happened (events should be named in the past tense): "I went to the store and bought some milk", it lets you know. You cannot reject an event (though it's possible your system is unable to process for some reason), because it is a declarative statement of something that has happened outside of your domain.
Commands represent something that a system would like to happen: "please go to the store to get some milk". A command is an asynchronous http request, essentially (and if designed properly, command handlers should be able to respond to all system edges), and it's possible you'll reject it because it it has not yet happened and is owned by your domain.
the above could use some cleaning up
It's possible that an event sourcing system will have different validation/etc requirements for commands vs events, but that's an implementation detail.