Rock-stars aren't toxic: they are disruptive.
What you do with the disruption they create is up to you: embrace it and elevate everyone else, or reject it, and continue with mediocrity (and maybe keep him as an ace-in-the-hole for skunkworks and one-off solutions where time is a key factor, and unleash the disruption when the time is right).
The companies that have a "stable" development pattern in which the feature development pace, bug rate, architecture, and organizational tools are "good enough" should not hire rock-star coders. They will be frustrated with everything you *aren't* doing, and all the other developers will wonder why he wants to push for more: after all, this has been good enough, right? Inertia will kill any ideas he has for improvement.
The companies that have highly-locked down roles and restricted responsibilities shouldn't hire rock-stars: you will underutilize them, and they will be frustrated with a lack of ability to "just get it done on my own".
Rock stars work well only when they are surrounded by true peers, and everyone is operating on their level, or they are in charge (at least technically) and can fill in a mentor role with not-quite-peers (and are given reduced responsibilities in other areas to compensate time-wise). This almost never happens: rock-stars are seen as too good to not be coding.