Scrum Master and the Sprint Backlog

do you also see situations / contexts where it can be meaningful for the Scrum Master to take a deeper look into the Sprint Backlog during the Sprint and to make recommendations?

As a Scrum Master you are responsible for managing other people's understanding of Scrum, so they might then implement it more effectively. Any recommendations you make ought to reveal, but you should refrain from attempting to resolve. 

That sounds very reasonable indeed, thanks! Although, as always, the line between "reveal" and "resolve" is probably very thin in some situations... I guess that identifying this line and not crossing it is one of the many competences that a SM acquires with experience

When in a coaching role, I prefer to minimize the amount of hands-on work that I do. I have found that it leads to the team expecting the coach, who is often a single-point-of-failure, to continue to do the work rather than learning how to do it themselves. Depending on the number of teams the Scrum Master is working with, looking into more details about how the team is working could be a good idea, but I wouldn't prompt the team to take any actions unless specifically asked. I would also use the Sprint Retrospective to ask the team questions about their way of working, especially if they are having problems reflecting on the way of working.

What happened during the sprint just only you do these works? What about other members? 

Do they think it is necessary to change to give suggestion? are they see this is a problem or only you?

Without the suggestion are customer satisfy with the produce they use?

Could we collect these data and analyze them together in retrospective?

Fist of all, question yourself first could you stop doing that thing but your team can take ownership? Beside that reflect your process why did not visualize these thing to your team and just only you see that problem?

...and occasionally add a comment (e.g. suggestion to change a tag or status, request to be more precise with the description of the item / task, etc.)

As a Scrum Master your job is to help everyone understand how the Scrum framework is beneficial.  The items you mentioned have nothing to do with the Scrum framework.  Those sound like procedural actions which a Project Manager might be expected to do.  As @Tai Nguyen pointed out the team should be the ones encouraging each other to do this if they see it as a problem.  

I really like the way @Ian Mitchell phrased reveal vs resolve.  I will be using that in conversations I have with others.  But I still don't think that the actions you mentioned are revealing anything directly related to Scrum.  A case could be made that you are helping with how to manage the Product Backlog but I think that is a stretch.  

Lots of very interesting food for thought, thank you!

I guess the main problem is that I used to be part of the team and then became its Scrum Master. Now I still need to fully adjust to the new role and lose my old habits...

You are still part of the team but in a different role.  You need to stop doing the job you were doing and start doing the new job you are expected to do.  Your old habits are still very valuable but your job now is to help them become everyone else's habits. 

Past experience doing a job is extremely valuable.  But you have to use that experience to help understand the current situations that a team is encountering.  You might work with a new team at some point that is heading in the direction that caused severe pain and frustration for an old team you worked with.  You should take advantage of that foresight, explain to the new team what you are seeing and how it impacted the other team.  Don't say "you are about to feel a lot of pain".  Say "a previous team found this to be counterproductive and here is why".   Help them learn from others mistakes.  It may be the team feels strongly about the path they are on but can now approach it with some caution.