The beginnings of what could be considered DPMI begin with Murray Sargent's SST debugger, which was capable of loading a real-mode (MZ) DOS executable into protected-mode and debugging it. Murray Sargent wrote one of the earliest "DOS extenders" to take DOS API calls made in protected-mode and translate them to real-mode calls. Taking Windows 2 and forcing it to run in this environment is how Windows 3.0 was born, and the code for SST ultimately formed the basis for DOSX.EXE.
Quickly, Microsoft realized that two different DOS extenders would be needed for 80286 and 80386 machines to run one protected-mode kernel, so a common (internal) interface was devised for the Windows kernel to perform operations such as allocating selectors. By Fall 1989, Microsoft realized that protected-mode DOS applications were becoming popular, but they mostly used the Virtual Control Program Interface (VCPI) specification to ask the memory manager to bring the client into protected-mode. The VCPI specification wasn't very compatible with multitasking, so all of those applications would be incompatible with Windows. However, Microsoft already had an API for protected-mode DOS applications, and it was used by a rather large protected-mode DOS application: the then-in-development Windows version 3.0. As such, they quickly documented the newly-christened "DOS Protected-Mode Interface" and spoke about it at a conference about OS/2 2.0. First of all, it's important to stress that DPMI is just documenting the internal interface used by the Windows kernel to talk to the DOS extender, opened up for use by any other protected-mode app. Second, it's likely that the DPMI support in OS/2 2.0 was built at first to facilitate running Windows (for WinOS/2) on OS/2.
It's worth noting that Microsoft never put out development tools explicitly tailored for making protected-mode DOS applications, as they saw them as a stopgap to bigger and better things (Windows and OS/2). DPMI was strategically preferable to VCPI, but a native Windows app was of course ideal.
The ability to run Windows 3.x as a client under memory managers / DOS extenders other than those included with Windows (DOSX.EXE for Standard Mode and WIN386.EXE for Enhanced Mode) was not altogether unheard of with Windows 3.0, but it was discouraged by Microsoft. While Microsoft did document the DPMI specification that Windows used, there were several blocking factors. One was that Windows wasn't quite a normal DPMI client; for speed, it mucked with the LDT directly (assuming specifics that held true for the Windows DOS extenders), and it depended on the undocumented MS-DOS API Extensions to allow INT 21H (along with BIOS and mouse calls) to be made from protected-mode. While Qualitas managed to reverse-engineer enough to run the Windows kernel under 386MAX, Microsoft still wasn't eager to document the MS-DOS API Extensions out of fear of allowing standard-mode Windows to run under other extenders.
By Windows 3.1, the situation had changed, and Microsoft modified DOSX.EXE (the DPMI host for Standard Mode Windows) to support operating as a VCPI client, meaning that it could operate within the context of a 386 memory manager. This is explained in a somewhat cryptically worded KB article on running Windows standard mode with EMM386 active that explains how "some third-party companies have released special versions of 80386 memory managers that allow a specific release of Windows to run in standard mode", referring to 386MAX in all but name. The article then goes on to explain that Microsoft chose not to alter the memory manager, but rather altered Windows to cooperate with any VCPI-compliant memory manager. In other words, they were saying that rather than add DPMI support to EMM386, Microsoft added VCPI support to Windows.
This can be viewed in one of two ways. On the one hand, omitting such support could be seen as a way to push people towards Windows. On the other, it could have been a contractual issue. Remember that the oft-told story behind the MS-DOS API Extensions being dropped from DPMI is that it was to appease vendors of DOS extenders (Quarterdeck, Phar Lap, Rational Systems, etc.) who would otherwise throw their weight behind (X)VCPI and leave DPMI without any clients. Including a DPMI server + DOS extender in a separately-bought product (i.e. Windows) was one thing, but a standalone DPMI server built into the DOS distribution was quite another. Recall that Microsoft did include the VMM from Windows 3.0 in early betas of C7, but removed them in favor of bundling Qualitas 386MAX as the DPMI server.
It's also worth noting that DPMI is a much heavier specification than VCPI; VCPI implements a handful of services, since it expects the client app to move into Ring 0 and do most things by itself. DPMI clients run in Ring 3, so they need more help and therefore a richer API (thus making a DPMI server a larger, more complicated program - best avoided by a key OS component sucking up both space on distribution disks and precious conventional memory). Many DPMI servers can also act as VCPI clients, so DPMI support doesn't need to be at that level, while VCPI support does. With that said, while a DPMI server with a DOS extender built-in would have rendered DOS extender vendors redundant, just a plain DPMI server (something Microsoft never shipped) shouldn't have hurt Quarterdeck and friends any more than a VCPI server. Indeed, that is the commonly-stated rationale for why the DOS extender bits were removed from DPMI: to force developers to target a given vendor's DOS extender rather than a generic one, and to encourage DPMI server vendors not to implement DOS extenders. Given that it was apparently removing this functionality that made VCPI proponents jump ship to DPMI, it makes sense that they'd see DPMI as a replacement, taking its place in memory managers.
This also calls into question Microsoft's rationale for not documenting the MS-DOS API Extensions. Based on the internal emails, there was no thought of contractual obligations with regard to DPMI; it seems to have been purely to keep the Windows DOS extender as hidden from public eyes as possible (KB articles also, as Andrew Schulman noted in Unauthorized Windows 95, go out of their way to describe the Windows DOS extender as little as possible) to shield it from duplication.
Nevertheless, if you wanted the advantages of enhanced-mode Windows, you were stuck running the Windows virtual machine manager. To date, no one has cloned the VMM. How then, does WinOS/2 support running Windows 3.1 in enhanced mode with Win32s (something which requires a VxD)?
The answer is simple; OS/2's DPMI server was extended to offer the same services that the VMM (and a select few VxDs) would provide. IBM essentially wrote their own version of the Win32s VxD!