I agree. If it's possible for the infection to "spread across the other websites in the same server", then that implies that clients can access and modify each other's files, which is not the case with any shared hosting provider I've heard of.
What is more plausible is malicious server-side code eating up server resources, and that load impacting the websites of other customers, but that has its own solutions which are different from automated detection of malicious JavaScript code.
Most of the compromises I've dealt with over the years fall into just a handful of categories:
1. Data theft. So, ripping off a database or intercepting credentials while people log in.
2. Embed a link into page output which will try to download something from somewhere somehow. It might be phishing, or (usually) it's some kind of JS trying to infect the user with malware. Lazy attacks work by just popping up a convincing-enough warning message with a link that lets the user download the malware themselves, and it's effective enough.
3. Credit card theft. Using a third party service with iframes makes this harder, but not impossible.
4. Dropping some kind of web-based shell, like C99.
#1 doesn't get anybody to care. If that's all that ever happened, I'm pretty sure shared hosting providers would still be saying, "sucks to be you." #3 causes headaches for the site owner and makes them care, but still not the hosting provider.
#2 got the hosting providers' attention once Google launched Safe Browsing. Suddenly this put some of the responsibility for maintaining a safe network back onto the hosting providers. Their first solution was to just shut down sites discovered to have malicious code, but that really irritated the customers. So gradually hosting providers started trying to be a little more helpful.
#4 is a big headache for hosting providers, because those things don't get picked up automatically by Google, and the shells can be used to irritate other hosting providers, who will definitely start lodging complaints with whoever's upstream of the hosting provider.
Not on this list is, "try to infect other sites on the same server", because shared hosting environments have had easy access to a variety of tools for a long time now that prevents that. In a LAMP environment, that used to include SuexecUserGroup; more modern LAMP environments now use php-fpm and have PHP processes running from distinct unprivileged user accounts. There's also the usual php.ini values, like open_basedir, which limit access to the filesystem or to other PHP functions (allow_url_fopen).
I won't say it's impossible for an infected site to attack another site on the same server in a shared hosting context, but you'll need a get-out-of-jail card and those are harder to come by.
No professional shared host would allow one site to access or modify another site on the same server.
It's not normally the default, but there's a world of bad advice out there telling people to chmod everything to 777 so that their PHP CMS can upload files.
The situation with default file permissions is already terrible enough that no host should ever have o+x on home directories. And once you remove that, it doesn't matter if everything inside is 777.
What is more plausible is malicious server-side code eating up server resources, and that load impacting the websites of other customers, but that has its own solutions which are different from automated detection of malicious JavaScript code.