There are, as has been pointed out to you in the comments.
Generally you don't see a lot of double-based engines in games because they aren't needed, and they might not be as fast as float-based ones.
The significant majority of games out there can work just fine using floats and the various techniques for doing world partitioning or readjustment that exist out there. They usually gain other advantages (or can gain them) by leveraging those kinds of partitioning techniques, as well, so there is some good synergy there.
Further, from a performance perspective, a game engine based on double-precision math (and thus double-precision matrix and vector APIs) can't take as much advantage of SIMD instruction sets, which are generally sized to allow for matrices and vectors that have 32-bit wide components. Those vector instructions can be a significant performance boost, and electing to use geometry representations that don't fit into the registers necessary for that instruction set means you don't get to leverage them.
The problem of interfacing with GPUs, which also generally want 32-bit component vectors, isn't quite as simple as you allude to in your question as well. Sure, you can recenter and downscale to floats relative to the render camera... but to get to view space you have to go through the graphics pipeline's transformation to world space, which means you have to have already submitted the geometry and coordinates as floats.
To do what you are suggesting there would involve short-circuiting the graphics pipeline by bringing all the coordinates into view space on the CPU, which is not nearly as well-suited to the task... especially if it cannot leverage the SIMD instruction set because the vectors don't fit.
You also have the problem of increasing the memory overhead of every coordinate component. This means a higher memory footprint overall, fewer such components fitting into cache at once, et cetera.
It's not a set of insurmountable problems. It's just that not very many games really benefit from doing so and thus the demand for middleware to support is proportionally low.
