There are two ways that XSS and SQLi could interact. The comment you quoted is from this question and is clearly regarding the first point.
SQLi via XSS
If you know that an application is vulnerable to SQL injection, but you do not have the permissions necessary to access the vulnerable component, you may be able to leverage an existing XSS vulnerability and thus get a more privileged user to perform the SQL injection for you.
As you point out, finding vulnerabilities in components that you do not have access to may not be that easy. There are still at least two cases where this can easily happen though:
- Open source software
- Temporary access to the source code (maybe via an external auditor, via Email leaks, via a disgruntled ex employee, via vulnerabilities in your source control, ...)
For very simple injections, an attacker may also just guess an attack (maybe an attacker knows that your application doesn't defend against SQLi at all, but all injections in components they have access to are using a database user with restricted permissions; here they might actually be able to guess script- and parameter names of other components and exploit those via XSS).
Theoretically, you could also imagine a setup where more privileged users are always using a database connection with a more privileged database user, so even an injection in public components may be more powerful if exploited via a more privileged user through XSS.
The last examples are a bit contrived, but certainly possible. There are likely other examples as well.
XSS via SQLi
In this case, you have an SQL injection, but cannot actually achieve anything interesting with it. The injection may take place with a very restricted database user, who for example can only read out already publicly available data (but cannot read out other data, write data, write or read system files, execute commands, etc; there are also no vulnerabilities in the dbms you can exploit).
In this case, you might be able to perform a reflected or stored XSS attack via SQLi.