This is actually a good idea in principle. The reason why this method will not work in the Bitcoin setting is that it is not Sybil-resilient. In particular, Bitcoin solves the problem in the anonymous setting, meaning that the parties participating do not know who else is on the network and more specifically do not know how many others are on the network.
If we imagined this idea implemented naively in Bitcoin, one could create a construction as follows: First, somehow maintain a list of all the nodes in the network (while from a network engineering point of view this is difficult, I will argue that, even if it were easy, the method remains insufficient), perhaps by IP. When nodes exit and enter the network, update that list. Every desired interval of time, say every 10 minutes, elect one peer from the network as "leader" in a globally consistent manner such that every node agrees on who is leader. The leader is allowed to produce a block within 10 minutes; regardless of whether they manage to produce a block within this timeframe, a new leader is elected for the next block generation afterwards.
Now let's think what the problem with this construction is: Because IPs are not authenticated and their allocation is somewhat centralized, you could imagine an adversary allocating multiple IP addresses and using one computer to connect to the network from multiple addresses. This increases their probability of being elected leader. An adversary who controls more than 51% of the IPs on the network would then be able to perform 51% attacks. While this might seem implausible, we actually know ways of doing it using, for example, BGP attacks. The critical observation is that such a mechanism would require an assumption of honest majority by IP address, not honest majority by computational power. This is a much stronger assumption than the honest majority by computational power assumption that Bitcoin makes today. Bitcoin's assumption makes it resilient to Sybil attacks because computational power cannot be faked in the same manner that IP address can be.
Lastly, let me say that there exist protocols which use your idea. However, they do not pick a network participant at random by IP address, but use other means for selection. One such example is the Ouroboros BFT protocol in which participants are chosen sequentially to produce blocks -- in this case the population is fixed and does not evolve. Another example is the Ouroboros protocol in which participants are chosen exactly as you describe, but with a weight which is proportional to the amount of money they own in the system -- here the population is evolving as money is changing hands (note that other flavours of Ouroboros, such as Ouroboros Praos or Ouroboros Genesis, do not work in this manner). Another line of work in similar directions is Algorand.
There are many subtle details on how to implement such protocols which are covered in these papers: How to do the random selection efficiently; how to do the random selection in an unbiased manner (or mostly unbiased manner); how to make sure all participants agree about who is elected leader; how to deal with people entering and leaving the network; how to deal with prediction of this randomness to harm the network; and so on.
