Regression Testing has always been a key concept for manual testing. Due to the nature of needing people to do it, with all that involves, it is important to identify a subset of key features to make sure they still work. This involves a lot of time and effort to create and maintain. All of which is time not writing application or automation code.
Companies that have moved to more automated testing have found the term 'regression testing' to be largely irrelevant. On of the key features of automation is that is runs fast and can be scaled. A consequence of this is that you should just run all your tests when making a change.
This doesn't necessarily mean running all tests as you make each small change. While making a change you will want to run relevant test layer suites. So for Unit testing you want to run all the Unit tests. They should be running in a few seconds to give the immediate feedback you need. This is achievable when you have stubbed and mocked ALL external services, database, filesystem, etc. Before merging the change to master however, the developer should run the full suite of UI tests.
In more traditional environments this will seem waaaaaaaaay too big a burden, this is because they have not adopted agile testing and still have an ice-cream cone for their test pyramid which emphasis on extensive and exhaustive UI testing. They still have factors such as '18 hour test suites' (or longer) that are essentially a liability for modern agile development. Continuous integration and getting used to branches running on your CI server is also a key part of this change. Ultimately part of the fix is also to monitor production releases and to perform Canary, AB and Feature flag releases.
Always question the value of a process and remember
Individuals and interactions over processes and tools
Working software over comprehensive documentation
and
Automation code, by itself, does not improve application code quality