When people talk about the maintenance cost of automated tests, the first thing that comes to mind is the cost of fixing things that break: APIs that change, UIs that are restructured, file formats that change, and so on. But you also need to keep the automation up to date with the feature it tests.
This isn't as easy as it sounds. It is possible that no one in your organization knows what specific test cases the automated test covers. With manual tests, you probably have some kind of documentation. The automation developer may have written something down when they first wrote the code. By default, the documentation will not stay up to date with the test.
The automation developer may remember what the test does if he/she still maintains it. On the other hand, if they're no longer on the project, there is a good chance that no one is keeping track of whether automated test is up to date with the feature it is supposed to test. Ultimately, the only way to figure it out may be to read and analyze the code.
With a product, if the feature set gets out of date, your users will tell you. With an automated test, the only output you really care about is PASS, FAIL, or ERROR. The test will pass regardless of whether it covers the new things the dev team added to the product in the last two releases.
A short time after it's written, an automated test becomes a leaky abstraction. People think of the automation as "The Thing That Tests Feature X" or worse, "The Test That Tells Me Whether Feature X Works", rather than "The Thing That Tests What Feature X Did As Of Release Y". Avoiding the leaky abstraction requires at the very least maintaining a list of what new things aren't in covered by the automated test. If you know that much, you may be able to bridge the gap with manual testing. Either that or you can ship bugs.
There are things automation developers can do to help with this problem. One strategy is to write things down, but as I mentioned earlier, documentation has to be maintained, just like comments in your code. Another strategy is to write your tests so that the test cases are separate from the test code. Sometimes this isn't possible or worth the trouble, but to the degree you can do it, it will be easier to discern what the automation does -- and what it doesn't do.