If something in the Signal protocol looks surprising, then the reason it's there is probably related to key compromise. The main thing to keep in mind is the fact that the "identity keys" are long-term secrets.
Suppose Alice has long term key $a^*$ and Bob has long-term key $b^*$, with corresponding public keys $g^{a^*}$ and $g^{b^*}$.
They can do normal DH key agreement with these long-term keys, and agree to the secret $g^{a^*b^*}$ and proceed to exchange encrypted messages.
But we care about compromise of long-term keys.
If Alice's long-term key $a^*$ is compromised at some later time, then the attacker can compute $g^{a^*b^*}$ and violate the privacy of the encrypted messages (in all of Alice's connections!).
If you're familiar with Signal, then you probably know how Signal recovers from key compromise under normal situations.
We use a "continuous asymmetric ratchet."
Alice sends a new/fresh $g^{a_i}$ with every message, and Bob sends a new $g^{b_j}$ with every message.
At all times, they can use the most recent $g^{a_i}$ and $g^{b_j}$ to derive the current shared key $g^{a_i b_j}$.
The important point here is that the $a_i$ and $b_j$ keys are temporary.
Alice can throw away $a_i$ after Bob acknowledges that he has moved on to using $g^{ a_{i+1}}$.
If an attacker compromises Alice at time $t$, this attacker learns only $a_t$.
After a short time, Alice and Bob will stop using $a_t$ and begin using $a_{t+1}$, and the attacker will stop being able to read their messages.
So, if continuous asymmetric ratcheting is the way to recover from key compromise, and we are worried about the long-term (identity) keys being compromised, then the natural solution is to do an asymmetric ratchet as soon as the connection is established (using the identity keys).
This is how I like to think of X3DH.
Think of the long-term identity keys as $a_0$ and $b_0$.
The parties can agree on a key $g^{a_0 b_0}$.
They also immediately send the next messages in their asymmetric ratchet: Alice sends $g^{a_1}$ and Bob sends $g^{b_1}$.
Then there will be ratcheted key agreements that give $g^{a_1 b_0}$ and $g^{a_0 b_1}$.
X3DH incorporates all 3 of these key agreements together.
Importantly, $a_1$ and $b_1$ are short-term secrets -- unique to this session, and discarded after the ratchet moves past them.
If a long-term key like $a_0$ is leaked, even the first messages in the connection are protected because the parties have preemptively advanced the ratchet one step, incorporating fresh values $a_1, b_1$.
This is the essence of X3DH.
The Signal specification looks a little different than what I described, because one of the goals is to allow parties to establish a connection asynchronously.
So we would let Alice (for example) precompute and post $g^{a_1}$ ahead of time, as a "signed pre-key".
When Bob wants to establish a connection with Alice for the first time, he fetches $g^{a_1}$ and then sends his $g^{b_1}$ to her.
In my view of X3DH, $g^{a_1}$ and $g^{b_1}$ have symmetric roles, but in Signal their roles are not quite the same -- one of them has been precomputed (Alice's "signed pre-key") and the other is computed at the moment of connection (Bob's "ephemeral key").
In the Signal spec, you will see the different terminology break what is otherwise a symmetry in the protocol.
