Flash pages, if that is what you want to call them, cannot be bookmarked. At least, forms and subpages within them cannot be. The same thing goes for working with the browser history (i.e. backward/forward arrows in the browser and the history in the View/History menu/sidebar).
A well designed website implemented carefully with AJAX, DHTML, HTML (or XHTML), and so forth - can be bookmarked. Just pay attention to your URIs.
AJAX is a feature users like when they see it. It can also make the web page much more responsible and seem a lot more useful.
At the same time, if the user has a noisy connection, they could get more problems and more complex failures than a traditional non-AJAX form that does not use any Javascript.
Furthermore, web browser bugs - like memory leaks, to name just one thing - are really going to be exacerbated by heavy use of DHTML (e.g. AJAX).
Javascript is built into the browser. Flash is not. Flash must be updated from time to time too, even if it did come with the browser. The Flash plugin is not particularly small.
Also, Flash lets a web page do things a Javascript-equiped page (or Java applet) cannot do. Some of those things, some users or computer owners/managers not want to let Flash do. You will be forcing them to allow it if you use them - they might reject your page. They might accept it if it uses Javascript/AJAX.
There are a lot of factors involved. Many of them will change for better or for worse, more than once, over time.
Besides, do you really think Flash will be around in 5 or 10 years?
Javascript will be and HTML or at least XHTML will be. Further, there are lots of free Javascript implementations out there. Far fewer Flash implementations, though.
Flash could be changed without notice, on one vendor's whim. Incompatible changes to Javascript would require a lot of approval and prior announcement lead time.
Javascript is an open standard. Flash is not.
The company that makes Flash has eliminated some significant products in the past couple years, as they juggle their priorities and eliminate duplication in the wake of mergers.
The possibility of such changes at one company affecting Flash are something to keep in mind in your "architecture". As architect, you have to be concerned with single points of failure, choke points, and risk analysis.
How will you maintain your Flash application when Flash eventually gets dropped, or a serious bug is discovered in it that affects your application - but it is beyond your power to fix the bug and there is no alternate implementation you can recommend switching to in order to run your application?