First, identity verification data for KYC is a little bit different from fast food or social media in that it's very difficult to live a normal life without being subject to any KYC checks. (I'm sure someone will chime in that they get paid in bitcoin and buy their groceries with cash.) If you are applying for some financial product or service that requires KYC, and they can't find any information about you, you will often either be denied that product or have to jump through a bunch of additional hoops to prove who you are. So it benefits CXOs to have their data included in these datasets, in fact if they are well paid they may well have more activity requiring KYC checks than the average person.

Second, and much more simply, one's own data often makes for a good test case since you know its accuracy.

It's not about what is right or who "should" do what, it's about securing the best outcome by making sure you and your manager have the same understanding, even if your manager isn't doing a good job of making sure you have the same understanding. (Also known as "managing upwards.")

I know it sounds silly/crazy but I have a use case where I would like to allow "mostly" trusted users to access the database directly and not through an API, but I need to apply some restrictions on their output.

I am interested in distributed systems and database internals (both traditional and new databases) but find that many database resources tend to be either introductory SQL queries or related to tuning.