Does anyone feel that defining a Sprint Goal is irrelevant for his environment?

The SG should not be defined based upon the features that have been selected for the sprint. 

The SG should be aligned with the PG and represent the value that the PO wishes to have created during that sprint.  The Developers should then select the PBIs that relate to the SG.  These are normally the upper most PBIs; however, they could also come from anywhere within the PB. 

If you create a SG after selecting PBIs, you are basically creating quality control after the item has already been created. 

Remember that the SG is there to help the team retain focus.

I like to think about the Sprint Goal as a focusing tool. It answers a specific question for the Scrum Team: If everything starts to go wrong in this Sprint, what is the one thing that we should be focusing on to deliver by the end? When you have a self-organizing, self-managing, cross-functional team, the answer to this question helps the team organize themselves around a specific problem and manage what they are doing on a day-to-day basis. There may be people who are working on stuff that isn't directly related to the Sprint Goal, but if something related to the Sprint Goal needs their attention, they know that they'll need to pitch in and help the team achieve it.

I'll also add that if you have a bunch of developers working on totally unrelated work, I'm not sure that you have a team, much less a self-organizing, self-managing team. You have a bunch of individuals working on their own problems and developing their own solutions. You may want to think about why the team is structured this way and if there are advantages to restructuring the team or how it takes on work.

In addition to what others have mentioned, I often see this happen in the following situations:

• The Scrum Team is supporting more than 1 product. The Product Backlog must align with only 1 product. 
• The Product Owner is an order taker trying to please too many stakeholders and has not been empowered to make his or her own decisions.
• The Product Owner is new to Scrum and does not realize that ordering a Product Backlog by cohesive PBIs can help the team stay focused with a Sprint Goal.

Most of the time the features selected for a sprint are totally unrelated

Why? What's stopping the team from selecting work which is coherent, and gives them shared purpose each Sprint?

A Sprint Goal makes a Sprint Backlog more than the sum of its parts. It allows a significant challenge to be addressed in a complex environment with many unknowns.

So who's making the selection and what are they hoping to achieve with Scrum? It sounds as though the environment you refer to is not thought of as being a complex challenge, just a complicated one with lots of bits and pieces.