There are a few reasons for this.
1. What constitutes a valid security report and what constitutes evidence of overall competency are not the same thing. Many bug bounty reports and vulnerability disclosures, even if they are valid, are not strong evidence of a potential candidate really being able to perform well as a stable, full-time security engineer. In the consulting industry this is especially problematic, where folks will try to jump into top firms like NCC based on a rèsumè of bug bounties disclosed to 20 or more well-known companies. They can find CSRF immediately by checking if there are CSRF tokens in the headers or request body and report instances like a numbers game. That says absolutely nothing about their ability to make a qualified recommendation about proper character sanitation mechanism to an engineering team, or about their ability to perform consistently over a long period of time (instead of jumping from bug bounty to bug bounty every few days or weeks).
To give an example, Facebook and Google routinely reward bug bounty participants who find real security issues by popping open Burp Suite and happening upon random errors - maybe a developer left a debug parameter in, maybe there is no restriction on adding phone numbers belonging to other accounts, etc (both of these are actual disclosures that happened and allowed arbirary account takeover). While reports like these are eligible for a reward, it's really not impressive enough in isolation because there isn't any evidence the submitter would perform consistently at a deeply technical level needed for the security team. Finding an exposed Jenkins server using nmap does not a security engineer make (another real example).
In contrast, security researchers who display a consistent history of valid bug bounty reports across a variety of vulnerability classes demonstrate a greater level of overall rigor and competence, especially if those vulnerabilities are more complex to exploit. Comprehensive reports like Stephen Sclafani's legacy API-based account takeover or Reginaldo Silva's OAuth callback remote code execution are much more likely to earn the recruiting attention of companies like this (and Silva now works on the Product Security team at Facebook).
2. This might come across as counter-intuitive, but it's often not all that helpful to send a company "suggestions" about how to improve security issues you've found. Unless you've found something actually high severity, they may not care about it all that much. At that point, you come across as someone who cares very much about something that is a marginal risk for them, or even a "Won't Fix." Sending a company an email about e.g. permissive CORS headers is going to be met with a "Thanks!" and not much else in the best case scenario, because while it's a valid observation it's not something that will cause a Business Continuity Risk alert for them. Furthermore, it's really not impressive enough a find to impress them (this goes back to #1).
Information security is ideally a collaborative process integrated into the SDLC; unless they have specifically welcomed suggestions (such as through an outside consultant), you are coming across as someone who is technically right, but utterly tonedeaf to that process. Good teams don't have suggestions put forward unsolicited from the void. As someone who has at best a limited understanding of the company's internal risk assessments, business goals, development resources and technical infrastructure, you're almost certainly not going to be helpful by doing this.
3. Pontificating. Almost all emails I have ever seen like this follow a similar format - a security researcher of unknown ability submits a report (the potential validity of which is inversely proportional to how famous the receiving company is) and identifies a security flaw. If it is a valid one, they then decide to launch into mitigation strategies as though the report is an audition.
This is often perceived as somewhat disrespectful to the receiving party's time, because suggestions are generally not needed. As an example, almost all reports like these are identifying low hanging fruit and/or well known security issues. The engineering team almost certainly recognizes the issue and probably has a good understanding of it if it is in the OWASP Top Ten or any sort of mainstream consciousness. To identify a valid cross-site scripting error and then pontificate about character sanitation and escaping strategies is unnecessary. Barring a huge organization that makes no effort to educate developers in security matters (in which case, why are you hoping to get recruiting attention by doing this anyway), you'll come across as someone reading from a textbook that everyone else has also read from.
4. The communication is inherently adversarial. Submitting a security report as an unaffiliated non-employee will be met with default:distrust reactions. You can resolve this by not making any of the aforementioned mistakes, but it's frankly not a good time to suggest working together. A better method would be to identify the vulnerability, have steady back and forth communication if the receiving party appears receptive, and then mention this successful interaction in a formal application or interview.
I'm not trying to take a side here, just pointing out how it is invariably perceived (consciously or otherwise) by the vast majority of companies.