Tales from the Evil Empire

I'd make one counter argument to this, though I agree with you for the most part. I wouldn't be opposed to a web framework in which controls could access certain properties of the page.

Bat only through a known interface and if the control degrades gracefully if the Page class didn't support the interface.

For example (inside the control):

IFrameworkPage specialPage = Page as IFrameworkPage;
if(specialPage != null)
//... Access properties of the page specific to this framework
else
//... degrade gracefully

One reason to expose properties on the page is if you want to access them after a Server.Transfer, or in Whidbey, after a cross-post. However, I forget whether those have to be public. Also, I suppose, a reason that people do that is to get access to control properties that are children of the page.

These are good points.
Mike's point is especially true, though I personnally don't like cross-page posting: even though we made great improvements in ASP.NET 2.0 in this area, I still think that when you go to a different page, there shouldn't be a strong coupling between both pages. And with the current mechanism, the target page relies on the source page inheriting from a special class or containing special controls. It's strongly coupled. I personally dislike this architecture and prefer to use weaker coupling such as querystring parameters when it's possible.
Mike's second point, though, is precisely what I'm arguing against, if I understood correctly.

You understand correctly -- my point was only that I believe that people sometimes use public page properties to expose control values. (Such an example appears in the docs, I see.) I just checked, and it seems you can use FindControl on the page B to get values out of A -- it still (kind of) breaks encapsulation, since it requires the target page to know the ID of the control to get, but at least it doesn't also require the container page (page A) to add a property to expose the control value(s).