I think it's generally true that the line between "developer" and "tester" becomes more blurry, and this is a good thing. However, even if the same person is writing production code and tests, that doesn't eliminate the need for testing specialists or experts.
The biggest concern is the maintenance of the testing frameworks. Just like the product, the test infrastructure needs to be maintained. There could be new versions of the libraries and tools to be evaluated and pulled into the project, requiring changes. Tools can become obsolete and superseded by other technology. The testing tools need to be integrated with various CI/CD pipeline parts to give visibility to the teams. Having a person or team of people to own the test automation framework and tools would likely fall onto a specialist team responsible for keeping up-to-date with the latest knowledge in this domain.
In addition to maintaining the existing tools, there is a forward-looking aspect for both tools and processes. Monitoring what the current state-of-the-art is in testing and test automation can help the organization maintain a competitive advantage. The core developers are probably looking at the tools, technology, and ways of working needed to design, build, deliver, and maintain the core product and remain competitive, but someone needs to do that for the testing framework. Again, a specialist team can take on this work, and it pairs nicely with routine maintenance of the tools.
Someone needs to be able to teach the developers what is necessary to use the automation tools. Whenever the tools or the process changes, the developers don't inherently have this knowledge. Having someone who can work with each of the development teams to keep their skills current as the environment changes is vital.
Some level of independence may also be necessary, depending on the organization's environment. Even if developers are taking part in writing automated tests, especially at the system and acceptance levels, having a non-developer review the tests against the requirements and ensure that they are good, high-quality tests can be the test specialist's role. The same person can be involved earlier on in the requirements and design activities to ensure that the outputs are clear and testable, and any interesting test cases are captured early on. This goes to having a tester's mindset to find the test cases that truly exercise the system beyond just coverage metrics.
Overall, I don't see QA automation engineers being replaced by developers. Instead, I see a shift in focus away from exclusively manual testers to people with a strong test mindset involved throughout the development life cycle. These people would lend expertise in test tools and processes to the developers and ultimately take ownership of product quality through a collaborative relationship with the developers. It takes a lot of skills to build software, and having a cross-functional team requires having all of those skills available in a way that enables others to level up to support the broader objectives.