Doesn't Content Service become bottleneck on SDL Web 8.5?
Yes and no. You're indeed in fact moving the processes, libraries and dependencies which fetch data from the Broker DB from the web app to a separate server or service. The effect of this is, that processes surrounding requests are spread across different JVMs, which in total bring a more scalable solution: you can use up all CPU and memory just to serve content from the database (cached or not) and you can use al CPU and memory of a web app server fully to render pages. If you had all this processing on one server, you'd choke it a lot quicker. And, as Bart already mentioned, it gives a lot easier deployment and dependency graph on your web app.
Further, looking at automated deployments and CI/CD practice, in this architecture it becomes easier to scale up the web apps without putting more pressure on the database if you use proper caching in the Content Service. If it's the case that the Content Services come under pressure, then you can scale those out as well, but you have to check database performance if you do that.
Looking at memory configuration that I've seen for CIS, I generally set as a baseline:
If you turn on caching however, then it becomes a matter of measuring your cache sizes under full load, for instance with VisualVM. I've seen instances where we configured a max heap size of 42 GB. It can also pay dividend to tune Garbage Collection, as is fully explained on the Oracle site.