I've seen projects where requirements changes are managed by a very heavyweight change control system. This is bad. Many important changes do not happen because the customer does not want to go through the hassle of submitting a change control, so the software doesn't match their needs. Some small changes get slipped in "under the radar" to avoid the process, so the software doesn't even match what you think it does.
Conversely, I've also seen projects where the project manager thinks "reactive" means getting the coders to respond to every request from the users, which just means you never get any core development done and your code becomes a big unwieldy mess of hack atop hack. Essentially you now don't have any developers, you have a team of overqualified sales engineers.
So one might hope there's a situation between these two poles that works well, and I expect that what works best for you is both a personal choice and situated. There's definitely value in capturing the cost of each change. In a framework like Scrum you can express the cost in story points, and the team can trade off the work they do in each iteration versus the total available effort. If you have a product manager you can get that person to quantify the expected benefit of a change or feature request. This is usually done in terms of protected revenue (how many customers would leave if you didn't do this) and attracted revenue (how many customers will arrive if you do do this). That can help with prioritisation, but can also just reflect the bias or personal preference of the product manager.