There are a bunch of ways in which you're not exactly correct here.
First, you're describing a very particular implementation of PoS. Not all PoS implementations include slashing. This isn't a mere technicality: the most popular implementation of PoS (as measured by market cap) is Cardano's and it doesn't include slashing. And not all PoS implementations involve randomly choosing a validator.
The bigger problem here is that proof of stake is actually a misnomer because doesn't actually provide proof, period--it's a consensus algorithm, not a proof algorithm. That's fine if you're actively connected to a bunch of nodes, because you can resolve double spends by polling the network to find out the consensus. But if you're only connected to two nodes and those two nodes are showing you two different spends of the same balance, you have no way to resolve that conflict. In PoW (a real proof algorithm) you simply look at the longer chain. In PoS, there's no way to actually enforce the longer chain, because there's no cost to producing a longer chain. This is a problem which occurs in practice when nodes newly connect to a network or reconnect after a long absence.
Slashing does nothing to address this issue. If I'm running a PoS validator node, I can stake coins, unstake them, and then spend the coins. Now I've got a free license to mine blocks without risk of slashing. I can mine blocks by simply validating blocks that say that I never unstaked. And I'm at no risk of slashing because I've already spent the coins: there's no balance to slash.
You alluded to an attempted solution with "it is solved by randomly choosing which validator will create the next block according to an algorithm that all the nodes follow" but that doesn't work: a provable random function can choose a validator which creates artificial scarcity, but there has to be a fallback in case validators drop offline, otherwise a downed node would grind the entire chain to a halt as soon as it was chosen as a validator and doesn't validate a block when it's supposed to. The malicious validator can use this because there's no temporality stored on-chain: you just find a situation where your staking address is the fallback node and claim that the validators who were chosen by the random function validated late, and nobody can prove you wrong. This may sound suspicious, but in fact these fallbacks happen in practice. To create a believable chain after this, you have to create a situation where a lot of validators drop off and are replaced by nodes you control. This also looks suspicious, but again this also happens in practice: for example if AWS S3 US East VA goes down, there will be a huge number of validators that drop offline.
Probably the most thorough explanation of this type of attack and the theory behind it can be found in On Stake and Consensus[1].
There's some debate on the importance of this attack--Vitalik Buterin calls this "weak subjectivity" and has written about it in length[2]. But to say he's not concerned about it would be inaccurate; he says, "actually implementing a proof of stake algorithm that is effective is proving to be surprisingly complex"[3]. That sentence was written in 2014 and Ethereum still does not rely on proof of stake in 2021--be assured that if in seven years Vitalik Buterin has not satisfactorily solved the problem, it's not trivial. I would caution anyone extolling the virtues of Proof of Stake from overstating their case--PoS is not a panacea and presents many challenges of its own.
[1] https://download.wpsoftware.net/bitcoin/pos.pdf
[2] https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov...
[3] https://blog.ethereum.org/2014/10/03/slasher-ghost-developme...