Software development is a continuous operational undertaking, like having a garden, and not a one-shot "task" like designing a logo. Systems need to be tended to and somebody needs to know how they work, especially if they're business-critical or (in the case of software companies), the business itself.
A corollary point is that many of the rules and policies of the business are solely embedded within the software itself. There is rarely a complete set of documents that says "this is how everything works" -- if you want to know how something works, you ask a software engineer, they take a look inside the codebase and then tell you how it works. In that sense, all software engineers are also product managers (or more accurately, product managers are just crude software engineers, but that's besides the point).
Yes! That's sooo accurate. Tools you use change, the level of abstraction you operate changes, but the role remains.
* Share knowledge about a particular area of the codebase between multiple people
* Share overall engineering knowledge between the parties in the review
* Ensure maintainability of the codebase long-term
* Ensure readability of the code
* Catch architectural/directional omissions (yes, from the planning/architecture phase) before it's really too late and non-reversible change goes in (eg. large destructive DB schema change)
* Ensure changes are small, self-contained, and as often as possible, reversible
* Do some basic manual QA
* Do comprehensive integration testing with a fully built-out system
...
* And yes, catch bugs before they hit production.
Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).