I think you need to take a step back and say "Are UpdatePanels the spawn of Satan?".
But seriously, the way you're outlining does have some fairly bad side-effects (although it's a possible strategy to go about working with dynamic content in ASP.net WebForms and I have taken a similar approach myself).
The first side-effect you'll have is that dynamically added content does not persist after a postback, so you'll have to re-add your UserControl to the Placeholder at Page_Init if you want to handle any posted form data. This can cause issues if you've got no way of telling which UserControl you added to the placeholder, but I've implemented such a solution before without this being too much of problem.
The second side-effect is the huge amount of ViewState you're going to collect as your UpdatePanels go about their business. ViewState is fairly evil, and when you're posting it to and from the server with every request, combined with it being very large, it can provide some severe speed issues from a user-perspective. I'd suggest if you do want to go down this route you should try to disable ViewState for any controls you do not expect to retrieve data from at a later date.
The other issue I can think of off the top of my head is the replication of page state. When you get a defect report from a tester (or user), with the dynamic UpdatePanel approach you will have to log a number of steps to replicate the state the system is at. If you approach from a URL-driven page load perspective, where each URL (with query string data) represents a page state the amount of time you'll need to take to track down an issue will be (hopefully) cut down to the amount of time it takes you to copy a URL and paste it into your browser navigation bar. I personally think this is the most compelling argument for trying to avoid a stateful approach web events whenever possible.