There are two factors here, speed of development and speed of execution.
All other things being equal, you're going to want something that's hardware accelerated. So your "2d engine' is going to be fundamentally a 3D engine, just using sprites and an orthographic projection. With that assumption there, there isn't much fundamentally different between a "2d" and a "3d" engine.
Now that being said, there are certain optimizations that you would do in a 2D engine that may or may not be built into a 3D engine. Batching of sprites (to reduce draw call count) is probably the biggest one. Depending on your 3D engine, this isn't terribly difficult to add. However if you have to add it yourself it's going to add some time to development. But in the end, in theory, there shouldn't be much of a speed difference other than additional overhead a "heavier" 3D engine may bring.
To help aid with sprite batching, it's pretty common that 2D engines have atlasing tools built in. Atlasing is combining a bunch of individual sprite images into one texture so you can batch more (as more things on screen are using the same material). Again, if you have to add this to a 3D engine, or do it yourself, it's going to hurt development time.
And on top of that it might be easier to do 2D physics with an engine with a 2D physics engine rather than a 3D physics engine with constraints.
But on the flip side, using a robust 3D engine gives you more options. You can have a fundamentally 2D game but not use an ortho projection. You can do 3D particle effects. Most 3D engines have nice skeletal animation systems and you can do interesting things with that (like attaching planes for body parts and animating a rig instead of spitting out more sprite frames).
At the end of the day it's all about your needs and your resources.