Setting the gn arg symbol_level=1 passes -gline-tables to clang which significantly reduced build sizes, bringing them down to ~75 GB. Using symbol_level=0 would break symbolizing stack traces. So we won't go lower.
optimize_for_fuzzing seemed to shave off ~5 GB from unpacked build size. 
Finally /OPT:REF will probably help quite a bit.

With symbol_level=1, compressed build size is 21.6 GB, which is comparable to ~18 GB for Linux.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/clusterfuzz/+/5fbc8e40b8f9fe639fa3f34599f1e7a065344126

commit 5fbc8e40b8f9fe639fa3f34599f1e7a065344126
Author: Abhishek Arya <inferno@chromium.org>
Date: Tue Oct 09 19:45:55 2018

> Setting the gn arg symbol_level=1 passes -gline-tables to clang

That's true on non-Windows, but at least in non-fuzzer builds isn't true on Windows. On Windows, sybmol_level=1 means that we don't ask the compiler for debug info at all, but pass /DEBUG to the linker so that it generates debug info with symbol names. In that setup, you still get symbolized stack frames, but without line numbers.

Oh, apparently that's not true in sanitizer builds:

  if (is_win) {
    # Linker symbols for backtraces only.
    cflags = []
    ldflags = [ "/DEBUG" ]

    # For win/asan, get stack traces with full line numbers.
    # AddressSanitizerTests.TestAddressSanitizer needs this, and since
    # win/asan isn't a default cq bot the build time hit is ok.
    if (is_clang && using_sanitizer) {
      # -gline-tables-only is the same as -g1, but clang-cl only exposes the
      # former.
      cflags += [ "-gline-tables-only" ]
    }
  } else {

Please ignore :-)

Build sizes are no longer so concerning, since  issue 884545  was fixed, they are now less than half the previous size, and the current size of Linux builds).