The cost of writing multiple wrappers can be amortized over many products, as generally once you write it, you use it repeatedly (perhaps with bug fixes and upgrades). Additionally that cost can be offset by, potentially, new sales on newly-support platforms that could not have otherwise been accounted for. Finally, many COTS middleware engines already have the multiple-API support baked in, so it's part of the cost of buying the middleware and usually not separable from that cost.
One reason to support multiple backends is that different backends may perform better on different platforms, and so having the option allows you to maximize the output on those platforms. For me, this is one of the most important. While OpenGL works on both the Mac and Windows and some consoles, it performs poorly on the consoles, usually. And on desktop platforms, relative to the primary APIs for those platforms (such as Metal and D3D) it tends to lag behind in support and tooling and ability to (readily) access cool new stuff.
Another is that the developer has to support platforms that cannot share a common backend. They must pay the cost of the abstraction wrappers anyway as part of doing business, and that lessens the overall cost of (perhaps eventually) adding support for OpenGL later. (In fact, many big games won't write directly against D3D or whatever anyway; they'll write against some kind of simplification layer even if they only expect to support one API, so even this can lesson the eventual cost of supporting many abstractions. Although perhaps not as much as intentionally writing that simplification layer with eventual porting in mind.)
A third is that the codebase needs to both support existing games on older backends like D3D9, but also be forward-thinking for technologies like Vulkan or D3D12.
It's also common to support it "just because" it's "cool" or as a learning experience.