Security leaves the meeting with mission accomplished, Engineers leave the meeting with pile of new work and less time to do it.
Here, the reason why it comes as a shock to devs is that they are often never taught about secure coding patterns and so build codebases that are very difficult to reason about, and don't express much interest in adopting more disciplined programming patterns to break the code into security boundaries that validate inputs crossing the boundary.
So if your webapp has 1000 controllers that make arbitrary queries against the data model, then only manual audits of every controller is going to give you any assurance of correctness. But if there is a separate access control module that acts as a security kernel and the controllers merely request services from it based on the current user context, then correctness is much easier to verify. But in organizations that refuse to adopt these models, they are forcing the security team to manually audit everything, which is an unreasonable amount of work to pile on them.
But there is a whole second thing that is meant when people say "security", which is the GRC space, infested with bureaucrats that bring lists of rules that are fundamentally code agnostic and often at odds with whatever codebase they are working on. So yes, in that case they are the ones walking blithely into a room, making unreasonable demands, and then leaving, creating a pile of work for the devs to do.
So it's often a dysfunctional relationship, but it doesn't need to be that way. Like anything else, things go sour when people are put in charge who either lack technical competence in the fields they are interacting with, or have this competence and just don't care about the size of burdens they are placing on others.