Ignoring the common trope that developers are bad testers (I am, but not all devs are), QA presence allows teams to move faster by reducing the developer test burden to automated regression, and developer acceptance testing only. Good QA can often assist with those tasks too, further improving team velocity. Also, moving tasks to people who specialise in them is not usually a poor decision.
The best way I've found to sell QA to management (especially sales/marketing/non-technical management), is to redefine them as marketing. QA output is as much about product and brand reputation management as finding bugs. IMO, nothing alienates customers faster than bugs, and bad experiences result in poor reputation. Marketing and sales people can usually assign value to passive marketing efforts, and recognise things that are damaging to retention and future sales.
The best way I've found to sell QA to management (especially sales/marketing/non-technical management), is to redefine them as marketing. QA output is as much about product and brand reputation management as finding bugs. IMO, nothing alienates customers faster than bugs, and bad experiences result in poor reputation. Marketing and sales people can usually assign value to passive marketing efforts, and recognise things that are damaging to retention and future sales.