This bundle still requires the TwigBundle to able to render the template, so why should this be extracted to a separate bundle?

@sstok I think that the error page functionality simply does not belong into TwigBundle. If we separate the bundles, TwigBundle will remain with just one responsibility - to "glue" Twig into Symfony Framework. Similarly ErrorPageBundle will have one responsibility - to bring fancy customizable error pages into Symfony Framework.
Right now, TwigBundle has both of these responsibilities. I can imagine that someone wanted to use TwigBundle without the exception handling.

This bundle still requires the TwigBundle to able to render the template, so why should this be extracted to a separate bundle?

In my opinion, "X requires Y" relation does not imply "Y contains X" relation.

I don't see the point. What value does it bring?

Recently, PR #20951 that redesigned the exception page was merged. I noticed that the new design looks different from the exception page that Debug component provides. Also, the highlighted code in TwigBundle's error page uses different colour schema than for example WebProfilerBundle's _profiler_open_file action. Lastly, the debug output from VarDumper component uses another (dark) colour schema. I thought that it would be nice to make them all share the same design (and ideally not violate DRY).
However, it took me a while to figure out what is part of the ErrorPage functionality (eg. which resources are relevant) and what is the other stuff in TwigBundle. So I thought that I could save other people's time in future by extracting it to a separate bundle to make it clearer what is what.

TL;DR: The point is less confusing code. However I would understand if the necessary changes and BC breaks were not worth it. :|

I don't see the need also, I'd be -1 here

The reason why the WebProfilerBundle duplicates the exception rendering instead of reusing the TwigBundle one directly is because we want to make the WebProfilerBundle UI available for Silex too for instance. So splitting ErrorPageBundle would not really allow sharing the code

Ok, I respect your opinions.
Just to clarify my intention: I wanted to make some component on which both ErrorPageBundle and WebProfilerBundle (and maybe DebugBundle) would be dependent. This new component would provide ways to implement the unified look.
The first step in doing this was to understand how all the different error page renderers work.
I had difficulties to understand which parts of TwigBundle are responsible for error pages and which not. Now that I discovered the details I thought that it may be nice of me to make it clear for others too by refactoring the code.
But I get that if the error pages generation code is touched very rarely it may not be worth refactoring it.