TL;DR Your question reveals no reason for me to assume that team building exercises are the cause of the problem. It actually sounds more likely that this is an attempt at fixing the real problems.
I apologize for the long answer but I genuinely urge you to read it. While there are some educated guesses in this answer; there are several points that I think you need to hear in order to re-evaluate some of your opinions.
You're trying to do the right thing, but I'm not convinced you're trying to do it the right way.
How do I tell this to the scrum master without sounding like an asocial jerk?
You can't, because the point you're making is inherently asocial. Note the difference between asocial and antisocial, the former is indifferent and the latter is adversarial.
There's no continuation to this part of your question - it's inherently impossible to not sound like the actual thing you're trying to accomplish (and no, lying is not something that is advisable anyway).
How would it make the team more productive if I know the favourite beer of a colleague whom I most likely won't ever meet in person and I don't even drink alcohol?
I want to dissect this quote, because it does a lot of heavy lifting in terms of revealing who you are at work and how you approach your workload. I want to be clear here: this is not a personal attack, I am making these points so I can then revisit them when we talk about the team's workload.
First of all, regardless of whether you think knowing innocuous facts about others is relevant or not; you then continuing about the pedantry of you "not even drinking alcohol" is a crystal clear indicator that you are getting distracted by the details of a particular fact rather than the bigger picture of discussing the value of these exercises at large.
If you have a bone to pick with the specific team building question about someone's favorite beer, that needs to be addressed in a very different context than one where you are picking a bone with your team's workload, delays and the overall existence of team building exercises.
Secondly, when working in a team, it is only natural for team members to at least know each other. This helps the overall flow of the team, otherwise there's no "team" to speak of. A team should not have any boundaries of (unreasonable) formality, conversation should flow freely to maximize the awareness and knowledge share between members.
Team building exercises are not exercises in extracting useful information from one another. No one is thinking that knowing Bob's favorite beer will directly help you achieve your deadline.
Team building exercises are attempts at breaking the ice between team members, in order to facilitate casual conversation, which is necessary when that casual conversation has been lacking in the team.
Sometimes these kinds of conversations happen naturally anyway (depends on the people's character and shared experiences) but sometimes people don't pick up conversations with strangers and are more able/willing to do so when there has been some prior conversation. The latter is exactly why team building exercises can be useful tools in order to build the team (hence the name).
There are eight people in the team, with fairly diverse backgrounds: some just got their college degree, some already have grandkids; some are working from office, some are in a different country, etc.
This sounds exactly like the kind of team setup that inhibits natural conversations, which leads me to believe this is why your scrum master insists on these team building exercises.
Your work issues
We're only about 6 months in the project, but already couple of months late, so I don't think we have much time to waste. Yet the scrum master insist on having retrospectives (i.e. long running meetings requiring the presence of all team members) every week and insist on "team building" games in these meetings.
The question as to why a project can run late is really broad. I cannot write an encompassing answer on that.
It is interesting to note that you point out the significant delays and are only picking at one particular thing that you dislike. So the first question that comes to mind is whether the team building exercises are actually related to the delays, and at least a major contributor to the problem?
Assuming that "a couple of months" is at least 2 months, over a 6 month span, you would have to be doing team building exercises for about 13 hours (1.6 work days) per week in order to have pushed your deadline by that much. I'm going to go ahead and assume that this is not the case.
For now, let's put the team building exercises aside. We'll come back to them.
The two predominant reasons for retrospectives running longer than you're comfortable with are either that people talk about problems without solving them, or that there's just so much going wrong that it takes a significant amount of time to even be able to address it. Given the kinds of delays you're dealing with, I'm leaning towards the latter here.
Even if everyone is individually working at a common goal, that doesn't mean they're doing it efficiently. There's a reason you're asked to form a team, not to be eight individual developers on their own track.
Assuming a team that has individually competent developers but effectively no good line of communication, the delays you're dealing with sound like they're in the right ballpark.
I'll admit that this is an educated guess, but I can even combine the two mentioned issues: the retrospective is probably chock full of the kinds of issues that make it clear that these problems would've been either mitigated or negated entirely if the team had been more acutely aware of the other members' activities and opinions.
So your scrum master is making you do team building exercises. You think this is a problem. However, your question reveals no reason for me to assume that team building exercises are the cause of the problem. It actually sounds more likely that this is an attempt at a fix.
This next part is going to come across as more adversarial towards you, but I genuinely intend it to counter some of your implied assertions in an attempt to get you to reevaluate your stance on things.
I can easily argue that by resisting to engage in the team building exercises and instead touting a more "face to the grindstone" attitude about what you should be spending your work time on; that you are probably a significant contributor to the team spirit issues that lie at the basis of the delays.
Don't get me wrong, it's clear that you like to work hard. Someone with a lazy work ethic would embrace these "time wasting" exercises with open arms. I don't think anyone here is question the effort you put in.
However, I'm going to openly question the efficiency of your effort. The adage is work smart, not hard for a reason. You're pushing a boulder up the hill and instead of taking a step back and trying to come up with a better solution, your proposal seems to be to stop trying to find solutions and instead just push harder.
This attitude works in the short term, but it will horribly fail in the long term. This is not a sustainable work ethic. If you persist with it, you run the risk of running the project entirely off the cliff, burning yourself out, and creating an inhospitable (if not toxic) work environment.
Sometimes, the better solution is to host a party, get people to come drink your drinks and dance to your music, talk to them; and they'll help you push the boulder the next day.
You're arguing that you could've been working instead of planning a party, and that is correct today. But how you spend your day is not what matters. What matters is how quickly you can get the boulder to the top of the hill.
If the party planning approach leads to you achieving this faster than just by pushing harder, then pushing harder is not the right decision to make. No one is giving you a star for your effort. You will be rewarded based on your achievements. High effort is not the best way to get there.
I genuinely believe that you intend well, but you are pushing yourself to blindly put in more effort instead of strategizing and coming up with smarter ways of tackling the problem in front of you.
And for a developer, that is definitely the wrong attitude.
I hope you will take this answer as it is intended: as a kind wake up call to revisit your metrics for success; because I've mentored several developers who were in the same boat. I was once in that same boat as well. Hand on heart, I do not intend to persecute you for causing the problem. I am hoping to convince you that you can help yourself and everyone around you by revisiting your stance on the importance of connecting with your team.