Sure there will be. It’s naive to think that there will ever be “one engine to rule them all”.
Game engine vendors will always be competing with one another to provide a solution that appeals to a given group of game, simulation, and application developers finding ways to leap frog one another along the way. This is why competition is good after all, us the game developers end up winning out just by acting as the fuel that keeps game engines alive.
As another example here, some of the projects I’ve been engaged in over the years requires a reliable means to display 3D content in a desktop’s web browser. Given our base, we can’t really depend on WebGL because A) WebGL still isn’t what I’d call a stable standard as of yet (with functionality being spread out across multiple browsers with different interpretations of how that functionality should work - in many ways it’s like desktop OpenGL in this regard), and B) WebGL isn’t a guaranteed feature that we can expect to exist in our player’s browsers and given how many users have a given browser preference we can’t just up and tell them to switch browsers to just to play a game. We also need our stuff to work on systems that may only support a maximum of SM3 if we’re lucky, with a much more common case being SM2 so even if we could distribute standalone executables UE4 is automatically out unless we make a lot modifications that may not even be worth the time and effort required. This pretty much leaves Unity as our only real choice thanks to its browser plugin and support for DX9-level hardware. Furthermore, you can still push more draw calls with a browser plugin that manipulates Direct3D or OpenGL directly than you can WebGL. Thinking two years down the road, that’s a situation that isn’t likely to get massively better even if UE4 and even Unity eventually implement ways to mitigate it - native browser plugins will still beat Javascript and WebGL.