Ctools is a remnant of the worst of the old fashion waterfall development method. Will Drupal 8 fix Ctools the way Drupal almost fixed Fields?
The full name for Ctools is Chaos tool suite and the only relevant part is Chaos. Some of the things in Ctools are tools while others are bits of code you can call to connect to Drupal core code, and are in need of a formally designed and documented interface. The random collection of functions and modules is not a Suite by any definition of the word given that the included modules do not interconnect or work together. The package is just a collection of modules. In true Drupal tradition, they should be split up and sold separately.
You do not install Ctools by choice. You choose a useful module and the useful module forces you to install the whole Ctools package despite needing only one function. Ctools is listed as having hundreds of thousands of downloads but there is no chance to measure what is actually used.
The waterfall development method is a big old dinosaur approach to development where everything is lumped together and you hope it somehow will magically work better as a result. Lumping all those unrelated modules together in Ctools is the waterfall method. Waterfall projects frequently fail because nobody can focus on any part. Big corporations lose billions every year on waterfall projects. In the past IT managers have called me in on year three of a two year project to save the day because, at the end of three years, the development is slowing down and looking like taking five years or more. Cancelling a hundred million dollar software project used to make news but it became so common that the media does not report anything less than a billion dollars.
Ctools has two forms related modules that should be split out for separate use. When split out, the modules could be properly evaluated. They might then be adopted by the Webform module and perhaps Drupal 8. As separate modules they can compete fairly against their biggest technical rival, the Webform module, and perhaps save the Webform developers some work. As separate modules, they can fight the political battle against whatever is in Symfony because Symfony advocates will fight to replace everything in Drupal with stuff from Symfony no matter how difficult it is to fit the replacement into Drupal 8.
Some packages fit together for a reason and become true suites. Ubercart is a package of modules that fit together as a suite of product/purchase/cart options. The Ubercart package includes a test payment system and excludes the dozens of modules for lesser known payment systems. You install the Ubercart suite, test, then add your payment module of choice. By comparison, Ctools is just a random collection.
Drupal 6 used to add fields through modules and CCK. CCK was presented for inclusion in Drupal 7. The Drupal 7 developers wisely split out some useful bits of CCK to form the Fields core module and left the rest of CCK. For Drupal 7, you can use fields without the massive overhead of CCK. You can also choose to use other parts of CCK as small optional stand alone modules. If Ctools was split up the way CCK was, you could use just the bits you need.
Usually I avoid any module listing Ctools as a prerequisite. You quickly end up with dozens of modules installed without choosing Ctools type packages. When you start replacing the dozens of modules with dozens of massive packages, you end up with hundreds of modules installed. Maintenance is a nightmare. Debugging is worse.
Drupal would benefit from breaking up Ctools today. Split out all the individual modules for separate download. The modules listing Ctools as a prerequisite should list only the individual modules, not the whole package. By the time Drupal 8 approaches a code freeze, there would be individual download and usage statistics for each module and Drupal 8 could incorporate just the frequently used ones.