X-Drupal-Cache-Tags and -Contexts headers are now only sent when developer explicitly enables them

Because:

1. Many hosting environments (and proxies and reverse proxies and CDNs) impose limits on the header size, and for a sufficiently complex Drupal 8 page, the number of cache tags on that page (i.e. the number of things that page depends on) can cause the cache tags header to go beyond 4 KB, causing WSODs.
2. When setting up a reverse proxy in front of a site that uses cache tags for instantaneous invalidation, these headers do not help much anyway: A) you need a Drupal module to talk to the reverse proxy anyway, to inform them which cache tags are being invalidated, B) commercial services require specific names (Fastly: Surrogate-Keys, CloudFlare: Cache-Tag) and a specific format for the value (Fastly: space-separated, like Drupal, CloudFlare: comma-separated). So, you effectively need a module anyway, so there is no point in always sending these headers: it doesn't actually simplify integrating with a reverse proxy.
3. Large headers slow down communication between client and server.

… Drupal 8 RC2 now no longer sends the X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers by default.

They're now something developers can enable, just like they can enable Twig debug output. And in fact, they can be enabled using the same mechanism as Twig debug output: enable them by setting the container parameter http.response.debug_cacheability_headers to true (in services.yml) plus a container rebuild.

Note that WebTestBase still enables them by default, so that it's easy to write cacheability tests.