I heavily favor end-to-end integration tests as well. For the kind of code you commented on, but also for older code bases w/out a hint of prior test automation. My experiences sound similar to yours - I've found they provide excellent understanding of general code paths and data movement, and that they help those remain stable during new development or refactoring w/out having to change too much within the code base.
Likewise on the controversy - my favor toward integration tests tends to get replies in favor of unit tests instead, in which case I'll say I understand their benefit and use them too. E.g. sometimes a method or class that handles some computation needs more coverage than what an integration test typically provides. Maybe the class or method gets called within an API, where inputs or contextual data are well understood. But it might also be called from back end jobs, or by code written by internal data teams where inputs or related data are more nuanced. In such cases, it's worked well to mock the class and go to town with various input or edge case data that might fall outside the perview of an end-to-end test.
Likewise on the controversy - my favor toward integration tests tends to get replies in favor of unit tests instead, in which case I'll say I understand their benefit and use them too. E.g. sometimes a method or class that handles some computation needs more coverage than what an integration test typically provides. Maybe the class or method gets called within an API, where inputs or contextual data are well understood. But it might also be called from back end jobs, or by code written by internal data teams where inputs or related data are more nuanced. In such cases, it's worked well to mock the class and go to town with various input or edge case data that might fall outside the perview of an end-to-end test.