Well, for a couple reasons:
First of all static linking makes it so you don't have to retain binary compatibility in future versions of op2extra. You could add / remove parameters or even remove functions totally and it wouldn't affect projects that had already been statically linked. This makes the job a bit easier on the programmer (since they don't have to remain binary-compatible with previous versions).
I think Eddy himself had problems with this (the renegades missions used a modified version of op2extra which was not binary compatible with the public version of op2extra.dll, which was part of the default OP2 install (as of 1.3.4)).
You also have the problem of new versions of op2extra.dll being released. If the mission uses a new version of op2extra, and uses new features from this version (all of which aren't present in the op2extra bundled with op2), the user running the mission has to update their op2extra.dll anyway.. so you don't avoid the DLL hell this way either.
Also, put it this way. For the same reason, when you compile an application with microsoft C++, you have the option of statically linking in the C runtime library, or dynamically linking to msvcrt.dll which is supposed to be in the system / system32 folder on the system.
Almost all applications written in MS C++ are statically linked just to avoid the DLL hell that results from not having the proper version of msvcrt.dll on the system. (or perhaps not having it at all).
Besides, the op2 missions already statically link with the C runtime library. (That's why a simple DLL is around 30 kb). Statically linking with op2extra wouldn't increase the DLL size much (a few KB at max).
--
Anyway, enough of my rant.