While others (and OP) give good reasons, beyond passion and interest, those I see are typically doing this without a bounty to a build public profile to establish reputation that helps with employment or building their devopssec consulting practices.

Unlike clear cut security issues like RCEs, (D)DoS and social engineering few other classes of issues are hard to process for devopssec, it is a matter of product design, beyond the control of engineering.

Say for example if you offer but do not require 2FA usage to users, having access to known passwords for some usernames from other leaks then with a rainbow table you can exploit poorly locked down accounts.

Similarly many dev tools and data stores for ease of adoption of their cloud offerings may be open by default, i.e. no authentication, publicly available or are easy to misconfigure poorly that even a simple scan on shodan would show. On a philosophical level these security issues in product design perhaps, but no company would accept those as security vulnerabilities, thankfully this type of issues is reducing these days.

When your inbox starts filling up with reporting items like this to improve their cred, you stop engaging because the product teams will not accept it and you cannot do anything about it, sooner or later devopsec teams tend to outsource initial filtering to bug bounty programs and they obviously do not a great job of responding especially when it is one of the grayer categories.