Graph or relational database is better for this tree structure?

TLDR; IMO a relational database would be better since your looking at how one thing relates to another, i.e. how many likes (of teams) a person has. You can easily update metadata on users, teams, or sports without worrying about messing up your analytic queries. Plus you can easily expand to add sport types like college, high school, or the like again without worrying that your previous set-up might get messed up.

BUT, I'll confess that I've never used a graph database before. :)

Doing a relation database might look something like this:

I like to call these info tables since they give just the information, some call them reference tables too, on a specific item: Sport (Sport_ID, Sport_Name, [etc]...) Sport Names like Football, Basketball, etc Example view:

╔══════════╦════════════╦═════╗
║ Sport_ID ║ Sport_Name ║ ... ║
╠══════════╬════════════╬═════╣
║        1 ║ Football   ║ ... ║
║        2 ║ Basketball ║ ... ║
║     ...  ║ ...        ║ ... ║
╚══════════╩════════════╩═════╝

Team (Team_ID, Team_Name, Home_State,[etc]...) -- Teams would be all teams, regardless of what sport type they were in. Example view:

╔═════════╦═════════════╦═════╗
║ Team_ID ║  Team_Name  ║ ... ║
╠═════════╬═════════════╬═════╣
║       1 ║ Boca Junior ║ ... ║
║       2 ║ River Plate ║ ... ║
║       3 ║ Spurs       ║ ... ║
║     ... ║ ...         ║ ... ║
╚═════════╩═════════════╩═════╝ 

User (User_ID, User_First_Name, [etc]...) -- All user ONLY specific information would go here. Example view:

╔═════════╦═════════════════╦═════╗
║ User_ID ║ User_First_Name ║ ... ║
╠═════════╬═════════════════╬═════╣
║       1 ║ Mario           ║ ... ║
║       2 ║ Gabriel         ║ ... ║
║       3 ║ Juana           ║ ... ║
║       4 ║ Raul            ║ ... ║
║     ... ║ ...             ║ ... ║
╚═════════╩═════════════════╩═════╝

Then you'd create the relation tables to make the connections between the sports, teams, and users.

Sports_Team (Sport_ID, Team_ID) -- Here you'd show which team played which sport. Example View:

╔══════════╦═════════╦═════╗
║ Sport_ID ║ Team_ID ║ ... ║
╠══════════╬═════════╬═════╣
║        1 ║       1 ║ ... ║
║        1 ║       2 ║ ... ║
║        2 ║       3 ║ ... ║
║      ... ║     ... ║ ... ║
╚══════════╩═════════╩═════╝

Team_User_Likes (Team_ID, User_ID) -- Here you'd show which person like which teams played which sport. Example View:

╔═════════╦═════════╦═════╗
║ Team_ID ║ User_ID ║ ... ║
╠═════════╬═════════╬═════╣
║       1 ║       1 ║ ... ║
║       2 ║       2 ║ ... ║
║       2 ║       3 ║ ... ║
║       3 ║       3 ║ ... ║
║     ... ║     ... ║ ... ║
╚═════════╩═════════╩═════╝

Now all you have to do to get a score of how many teams a user likes is:

SELECT tul.User_ID
     , COUNT(tul.Team_ID) AS Likes
  FROM team_user_likes tul
 GROUP
    BY tul.User_ID

And if you want the user metadata, like their names, you can throw this query into a CTE and then use the user table to join to the CTE table.

This might look and sound complicated but it will make it easier to edit/update user/team/sport information. You'll be able to do some interesting analytics like how many user like/prefer one sport over another using the like data without having to worry about affecting the relational tables, or which team of each sport is the majority favorite.

Plus this should scale easily, depending on what relational database you use. And say you wanted to start adding high school, college, etc. sports, you could just add a sport_type table then create a sport_sport_type relation table to make the connection of which sports are professional or one of the others. Viola, you can then do analytics by sport type without worry about how it affects your previous set up.

I prefer relations databases because they seem to keep things tidier. That all being said, I have never used a graph database. But considering that your seeing how one thing relates to another, i.e. how many teams a person likes, my opinion is that you should go with a relational database.