I think there's one more piece to the answer that I see being hinted at in others' responses, but not directly called out.
Often, automated tests are created in such a way that even non-essential details are locked in and executed the same way. This leads to what has been referred to as the Pesticide Paradox or the minefield analogy. Bugs are found when the test is created, and then the test effectiveness at finding new bugs drops as the test does the exact same thing over and over every time without variance. In some cases, you might want this behavior - barricade tests like Bruce describes, regression tests designed to look for the recurrence of certain data-specific bugs, and such. For many people, it seems like this is all automation is which is where the conventional "wisdom" of automated tests not finding new bugs comes from. In this scenario, the test's greatest bug finding effectiveness is at creation time. After that, as bugs gets fixed, it moves more to a "providing ongoing confidence" model. It may occasionally find a new bug that gets introduced, but barring any direct changes in that part of the application, it may never find further problems.
It is possible, however, to create tests that extend their bug finding effectiveness past their initial creation. By thinking about each test and identifying what is critical to the test and what is only specified for convenience or repeatability, you can take advantage of the non-critical aspects for the test to provide variance.
For example, I work on a healthcare information system. A test for registering a new patient obviously needs to actually register a patient. We might have separate tests for registering a patient through the hospital admittance, through the emergency room, or through pre-scheduling an admittance. However, depending on the test, it might not matter whether the patient is male or female, or born before 1930, or all sorts of other aspects that we'd probably say shouldn't matter. We could create automation that uses a given patient record to add, and have it do the same thing each time, perhaps even having done some analysis of test data beforehand to manually vary some aspects of the patient across the suite, but this single test would always do the same thing with the same data. We could also, however, hook the test up to a fake data generator and get broader variance in this particular test scenario to catch things beyond what we initially identified. This method would likely take more coding - you'd need to get the expected data values to the places where the verification occurs in addition to the places where it's entered, handle the variance throughout the code, and if repeatability is important in the context of this test, you'd need some way to either reuse a specific random seed or create a log file with an executable version of the test with hard-coded data or something like that, but the test would have the potential to find more bugs. In this case, each time you run the test it has the potential to find a new bug because it may be a "new" test in some way. We might be right and the things we're varying really don't matter, and in that case that we still won't find any new bugs. If we're wrong though, and something does matter, we have a better chance of finding it than if we never vary anything.