Features - branch 2.x results in large info files that exceed the 'info' column limit in the 'system' table
The way I see it, you have options:

Features

Break your Features down into smaller Features.  Yes, this might make the dependencies a little more effort to manage, but a Feature containing that many content types, as well as other config does seem a little extreme.

If you do break them up, and are worried about dependencies, create a controller module to deal with them.  Every time you add/break down a Feature, add it as a dependency to this controller module, then make your new Feature depend on the controller module.

This means that all other dependencies will be inherited by the Feature, but you've only had to declare it in one place. When you then disable any part of your Feature, everything will get disabled - which is the same behaviour as having one monolithic Feature.

As an added bonus, if you perform updates to your Features that require hook_install or hook_update_N, they can go in the controller module.

Configuration Management

If the idea of breaking down your Features really sends shivers down your spine, then check out Configuration Management, which can do what you want (track EVERYTHING), and if pretty easily extensible if you are happy writing your own code. This is also the route Drupal 8 is taking/has taken with configuration management, so with this method you'll be future-proofing your own knowledge.

My personal preference is Features, but if you are looking for something that wouldn't involve you breaking down a huge Feature into smaller ones, then Configuration Management is a solid option.