Both command sourcing (CS) and event sourcing (ES) rely on determinism for correctness.
The correctness condition for ES is the determinism (purity) of the function State -> Event -> State. Given that this function is deterministic, aka it always maps the same inputs to the same ouputs, we can rely on it to reconstitute state at any point in time. Determinism is typically achieved by ensuring that the Event has all required information to make the state transition, ie no side effects. The Event then is a sort of "closure" of all pertinent information about the event.
The correctness condition for CS is the determinism of the function State -> Command -> Event. Herein lies one of the distinctions between command sourcing and event sourcing - a program can control its output, but it not its input. Since one can't control the input, aka command, one can't in general, enrich it with all required information to make the above function deterministic. A consequence of this is that you can't simply replay a stream of logged commands at some arbitrary time and hope to get the same outputs as you would if they were handled immediatly. The other difference of course is that the mentioned ES function is used for reconstituting the state and the CS function is used to react to an incoming command.
Disregard the semantic distinction between commands and events and consider instead the more abstract notion of input and output. In this sense, a service, an aggregate, a projection, etc can all be though of as a programs mapping input to output. In other words, they are all state machines - a finite state transducers in particular. Command sourcing is just State -> Input -> Output. The input need not be thought of as a command and indeed, a command can be thought of as an interpretation of an event as discussed here.
As a practical example, I'm currently building fully event sourced system using EventStore. Output streams produced by some programs are used as input streams of other programs. In this sense, I have both command sourcing and event sourcing.
How about journalling of all commands. Deterministic system using such approach e.g. VoltDB, SLOG (and most decent trading systems e.g. Matching Engines like Nasdaq or best dark pools, Order Management Systems - only low latency ones, and other mostly buy side transaction processors). The reasoning - flow is very predictable and simple, zero-copy processing (network/OS buffer to local store changes) and lower latency using distributed state machines.