Almost all engines that support deferred rendering use still allows for forward rending, its not a take it or leave it deal. Deferred rendering has its use cases and solves certain problems (primarily when dealing with many dynamic lights), however it also has many drawbacks. Some things you simply cannot do (or is severely impaired) with deferred rendering, such as transparency and anti-aliasing, and requires to use the more traditional forward rendering pipeline as well.
If you do not require it, then there is no need to implement it. If you want to learn more about it, then go ahead and implement it (its nowhere near as complicated as it seems at first, its actually quite simple). Its not a major architectual decision for a small project (although it has pretty heavy implications on your material/shader design), so you can always try to implement it down the road if you wish.
Basically, its not as complicated as you think. If it seems interesting than go ahead and implement it, although unless you are dealing with the problems it solves (large number of dynamic lights primarily), you can get by without it [as games have been doing for a long time].
As far as engines heres a few i know offhand,
Unity - uses both forward and deferred paths.
UE3 - I believe was only forward rendering
UE4 - All lights go the deferred path, transparent objects go through forward pipeline.
RAGE - Supports Deferred rendering
CRYEngine - Supports Deferred Rendering.
As you can see, most engines still provide a forward pipeline, as deferred isnt a golden ticket. Do what makes sense for the data you are dealing with and the problem you are trying to solve, not whatever is the latest fad that everyones using (thats more general advice though).