I am trying to fully separate RSA key pairs by breaking down (N,e) for public part and (N,d) for private part.
There are performance, security and compatibility drawbacks to putting an RSA private key in the $(N,d)$ form. It's generally best to use the full form $(N,e,d,p,q,d_p,d_q,q_\text{inv})$ standardized as RSAPrivateKey by PKCS#1. If small private key size is paramount, we can use $(p,q,e)$, which is enough to easily compute $N=p\,q\,$, $d=e^{-1}\bmod\operatorname{lcm}(p-1,q-1)\,$, $d_p=e^{-1}\bmod(p-1)\,$, $d_q=e^{-1}\bmod(q-1)\,$, $q_\text{inv}=q^{-1}\bmod p$. While it's possible to factor $N$ from $N,e,d$ and find the smallest $e$ matching $d$, that's relatively complex.
The $p,q,d_p,d_q,q_\text{inv}$ terms exist to allow using the Chinese Remainder Theorem when computing $m\in[0,N)$ from $c$ with $c=m^e\bmod N$, and the private key. It's computed $m_p:=c^{d_p}\bmod p$, $m_q:=c^{d_q}\bmod q$, then $m:=((m_p\,q_\text{inv}-m_q)\bmod p)\,q+m_q$. This allows a large work reduction (by a factor up to nearly 4) compared to $m:=c^d\bmod N$. OpenSSL does that for signature at least when it has the private key in full form. That would also allow parallelization (for a total speedup by a factor up to nearly 8).
Often the absence of error during use of the private key is insured by verifying that $m^e\bmod N=c$. That's especially useful to avoid the Bellcore attack when the above CRT method has been used. However the check still is a good idea even when $N,d$ is used rather than $p,q,d_p,d_q,q_\text{inv}$.
I guess the OpenSSL signing process requires $e$ for said verification. Also, it needs $e$ to convert a private key in short form into the full form, which some code path does. Update: poncho's answer gives a better explanation than my guess: that $e$ is required for side-channel countermeasures.
