IMHO, it depends on how much you are "developing" in PPM really.
If you have lots of custom screens, reports, processes that you need to test through various production cycles then perhaps it is useful, although I would think that automated testing is something that the product developers (i.e. CA!) would be using rather than the user-base - we should have a reasonable assumption that the product is well tested.
I have looked at this in the past though, but dismissed it as an unwanted overhead - the creation maintenance of the test scripts (and the debugging of them!) appeared to not be worth the effort in pursuing - this was very much a gut-reaction though rather than based on empirical analysis, I concluded that we were not mature (nor complex) enough to gain benefit from automated testing.
Things that concerned me were the fact that I was not in control of the underlying technical field names - I was concerned that CA might change those as they upgraded versions (this was around the time of the v12 -> v13 upgrade) and I was concerned that the "new UI" in V13 would cause extensive rework in any automated scripts we had developed. I would have similar concerns today with the "even newer UI" in the current releases of PPM.
If you have a good reason to be doing automated testing and are comfortable using the tools, then of course it is a good idea, just one I could not justify at the time I looked at it. I have not been in a situation since where I thought it would be of benefit either.
(I think my main concern was having to "debug" any automated test-scripts when something went wrong, it was bad enough having to debug any "Clarity" code that I may have produced )