The are only three drawbacks of using this scheme that I am aware of. The first is that it can complicate things if you have more than one form, as far as the UI is concerned, that might require a separate "default button." The good news is that there are at least a few workarounds for this, and if interest is expressed, I will expand in a part two of this article on how to do that.
The second drawback is that ASPX Intellisense is not enabled for most of the server controls when you remove the HTML and BODY tags from the ASPX (which you should if you're using this scheme). There are a number of workarounds for this. You can read about a creative one at Paul Wilson's Page Templates: Designer Issues. I've found that temporarily adding the BODY tags enables Intellisense. You can them just remove them or comment them out when you put the page into production, although I've found that leaving them there doesn't appear to hurt anything. Hopefully, the next release of VS.NET will account for this and provide Intellisense on such ASPX pages, as they do now for ASCX pages that also do not have HTML or BODY tags.
The third is that you cannot use ASP-style code blocks (e.g., <% ... %>) on the page. For whatever reason, ASP.NET marks control collections as read-only as soon as you add a literal with code blocks, so further modification cannot be made to the tree. I have asked around extensively and have yet to find a solution to this. A workaround is to simply not use code blocks. There are a few instances where using code blocks might make sense, but generally I think it's a bad habit and holdover from the ASP model that should be avoided.
