It depends on how you plan to use it, IMO.
1) If the site will absolutely fail without it, you are excluding users with scripting disabled. I think it is fair in many scenarios to limit but not remove functionality for no-script users (for example, Google doesn't autocomplete searches if you have scripting disabled; it can't...but the basic search still works).
2) The right techniques need to be used in the right place. For example, an ASP.Net UpdatePanel will perform horribly if you dump thousands of elements into it.
3) I am becoming a bigger and bigger fan of content that is loaded in small blocks on the page that does not require a full refresh NOR does it require the whole page to be executed again. This lends itself to a SOA nicely, but is even more subject to the limits of #1.
4) EDIT: Don't create UI elements that (due to AJAX) behave unexpectedly. For example, I once built a dropdown list that only populated when it was toggled. Because of latency and DOM creation time, it wasn't responsive. Furthermore, the size would often change based on what elements were dynamically added. You could propose ways around these problems, but that was still an incorrect use of the technology.