I think the shortest answer is.... "depends on how you're
organized at your shop".
In here we use the native DB2 option, and we don't use a
separate group for security (so that means we don't separate SECADM
from SYSADM), and we didn't like the option or handling security
with RACF. Personally I don't have any issues with any option, but
the real problem was in the team:
Let's say, for example, that you have the idea of setting up
trusted contexts and you'll revoke any individual privileges to
remote applications users, so that means a complete reorganization
of the security environment, policies, and even internal paperwork.
The problem is... who's going to do what? If you're working with
RACF, they will, at some point, require to hire a DB2 guy because
chances are they only know RACF for traditional z/OS security, and
same thing would happen if you assign SECADM to non DB2 people.
I've also seen that the DB2 guy from RACF will quit shortly
because, well... he's a DB2 guy after all. That's just an example
of what I've seen over time.
I like the three options BTW, but they all require a very very
very detailed planned organization.
Hope that helps,
Certified DB2 11 for z/OS System Administrator. Mexico