Hey Anthony, couple of answers from two different perspectives:
From the bug bounty perspective:
1- One way to avoid submitting self-XSS in bug bounty programs that don’t have a measurable impact is to think about how the vulnerability you are submitting in your report gets exploited. What actions does an attacker have to take in order to exploit this XSS vulnerability? Does it require another user’s interaction? If so, what would the user have to do to trigger it? Would they have to copy/paste the payload in their own browser console? If so, that’s self-XSS. In addition to that, think about how you would do something practical with that vulnerability. ie: here’s exactly how I would steal an admin’s credentials, or here’s how I would steal a user’s billing information.
So before I submit a report, I always try to answer – in detail – the question: “How would I successfully exploit this vulnerability if I wanted to do damage?” If I can’t answer that question in my report, my work isn’t done yet and I don’t have a proper report.
From the victim of self-XSS perspective:
2- One way to avoid being the victim of self-XSS social engineering is to never copy/paste code that someone gives you in your browser’s console unless you are 100% certain of what it does. Though honestly, this applies to copy/pasting code even outside of your browser.