This is easy to implement and is basically found money, so we'll be doing it ASAP.
My expectation is that an Amazon (LB) access point is more reliable than a generic EC2 instance. For these components, we'll be paying less for something that's both more reliable (hopefully) and easier to manage.
Auto-scaling is powerful and easy to set up (even in the private beta, before tools were available), but as we're heavily integrated with RightScale (specifically, using templates throughout) migrating to pre-configured AMIs would take some effort. We'll have to do some internal review before making a decision on rolling out auto-scaling to existing apps.
Monitoring is, as expected, also provided by RightScale. Amazon requires you have CloudWatch turned on for instances in auto-scaled pools (for obvious reasons), so that's one way we may end up using it. RightScale's blog post mentioned they'll be integrating their alerting and reporting with CloudWatch, but I'm not sure it's worth the extra $0.015/intance-hour to have the data come from Amazon instead of RightScale. I expect that, for now, CloudWatch is more relevant to:
1) users not on RightScale, Cloudkick, etc.
2) users who want direct access to their monitoring data (for archival, custom graphs, whatever - not currently possible with RightScale, not sure about other cloud management vendors)
Amazon's move up the application stack (Elastic MapReduce, for starters) may create additional use cases for CloudWatch, but that's entirely up to Amazon.
What I'd really like to see in the near-term is an open source tool to read in and graph CloudWatch data that's been archived somewhere (SimpleDB would be cool, but S3 would work too). Of course, I can see why people would be hesitant to start down that path given that Amazon has a console that's begging to include this functionality.
-Mike B @ ShareThis