Our team is developing a rather big ASP.NET web project which initially started in ASP.NET 1.0 and was ported several times to all new versions of .NET.
We made extensiv
I would use usercontrols still, and mainly because you can disassociate content from design this way much more easily which will ultimately help a lot when you are changing the design of the application.
It also makes it a bit easier to move the controls around on the page than if you had to cut/paste code all over the place.
Used correctly, user controls improve maintenance and reusability, and very often are faster to create than server controls.
You mentioned that in your previous project, very few of the user controls were reused. This seems to be more related to poor planning than an inherent flaw in user controls themselves.
I guess a good rule of thumb would be to look at your design and see if you're using the same set of controls over and over again, in which case it does make sense to use user controls.
It does purely come down to the type of web application which is being designed. At work one of our applications is very configurable so works on one page (default.aspx) and loads in controls depending on how its configured for the logged in user.
However, on the flip side, if you are writing a web site which needs to be accessed through SEO and has to be easy to navigate then implementing each view in an aspx page is a good way. Makes accessing each page during development easy and straight forward as you can access it directly (assuming no security permissions / logic get in the way) through setting it as your start up page in VS.
Another option to throw into the mix is using ASP.net MVC; interdependant views with re-usable usercontrols also thrown into the mix :-)
We have some projects which use ASCX controls extensively, and others that don't. In my experience you have to decide on a case by case basis.
My two favourite reasons for using ASCX controls are:
ASCX controls can be useful, but you really need to make sure you only use them when there's a good reason to - otherwise - as you say, you can be adding unnecessary complexity into your codebase.