Benefits example

On the project page, you have several answers to your questions already:

Performance

- This allows css and javascript aggregates to be built by multiple, parallel threads during cold starts. Core currently builds them inline during the page rendering process can add around 900ms to serving pages that do this.
- Removes runtime file_exists() checks for css and js aggregates. These can be very expensive on systems running with NFS file storage or similar and occur on every page request in core.

Disadvantages

You need clean URLs and CSS/JavaScript aggregation to be enabled on your site. Otherwise just enable the module. You may need to clear page cache (or varnish if using that) after doing this since aggregate file names will change.

I did some pretty primitive testing with http://simplytest.me but found that with just Core & no actual content that Drupal's defaults did slightly better than agrcache's results using http://loads.in

Now this is by no means a scientific process and they were always within 0.3 seconds in my testing, but still some comparable numbers would be useful or suggestions for sound testing methodology for testing/evaluation.

In principal I do agree that your approach, but looking for clarity.

It also removes the variable_set() usage to track drupal_js_cache_files and drupal_css_cache_files, which can be a problem on some sites.