The problems with frameworks start once you need to combine two frameworks. The C++ world suffers greatly from this because every framework implements their own String type for example, and they are all incompatible. In Perl, once you move your application to POE (for example), you'll find you have big problems adding Tk (or even threads).

There don't even need to be two frameworks. If you have existing code, you likely have to rewrite it to fit the framework you choose, because the target framework wants to call your routines in a specific order (Maypole as an example), or wants a different partition of the program flow (POE as an example). Using threads or Coro can migitate the problem of competition for flow of control by giving the framework its own flow and communicating through messages, but you trade that for a new set of problems.

The fact that any framework prescribes how to approach a problem is why I prefer libraries (which my code calls) over frameworks (which call my code). I found that in the long run, I'll always end up in corners where I'm working more against the (limitations of the) framework than using it to its advantages.