Tickets in a Sprint: should the current Sprint board contain all the ongoing tasks?

Never mind what someone worked on yesterday. What plan is the team going to come up with for the next 24 hours to help them achieve their joint Sprint Goal commitment?

If a Developer then diverges from that plan and the others don't know about it, what are the consequences, and what remedy do they propose?

The decision about the granularity of the work on the Sprint Backlog, on the Sprint board, or however the team tracks and visualizes their progress in the Sprint is purely up to the Developers. Key stakeholders may have some input to make sure that they get the appropriate visibility and don't need to bother the team for updates, but the final decision is up to the Developers.

Instead of making sure that all of the tasks are on the board, I'd be more concerned that the team is working on things that support the Sprint Goal or that help to progress Product Backlog Items that were selected for the Sprint, with the primary goal being to make progress toward achieving the Sprint Goal. If the work being described is in support of the Sprint Goal, then it should be associated with a Product Backlog Item selected for the Sprint as well.

I'd also agree with Ian. What was worked on yesterday, or even prior to the Daily Scrum, is of little importance. The most important is what the team needs to do next to achieve the Sprint Goal. If someone worked on something and they now need someone else's help to progress the work toward Done and move the team closer to the Sprint Goal, getting that help is what is important to talk about.

How would you make people aware of the importance of creating tickets for the tasks they perform (it can be operational or not) and to add them to the board/Sprint? (How would you deal with that?)

As a Scrum Master I don't care what tasks are being done.  All I care about is whether progress is being made on the Sprint Goal and if the Developers think that they can satisfy the goal.  As a member of the Scrum Team, that is my sole interest during the Sprint.  The Sprint is for the Developers to deliver on a Sprint Goal that is crafted by the entire team.  The Developers are allowed to organize that work in any way they see fit in order to satisfy the Sprint Goal. 

As an outsider, my question is why the Scrum Master was present for the Daily Scrum? That event is for the Developers to plan their days events.  There isn't anything that they discuss that is of any concern to the Scrum Master. If the Developers feel that the Sprint Goal is in danger, they should initiate conversations with the entire Scrum Team (Scrum Master, Product Owner, Developers) to discuss how to mitigate the situation. 

Before you say, that you are there to make sure the Developers have the event and that it is being used correctly, I encourage you to look at whether that is necessary.  Can't you tell that the Daily Scrum is occurring by viewing updates to the Sprint Backlog?  Can you see that it is serving the intended purpose by seeing progress towards the Sprint Goal?  

I would say it shows a lack of Transparency. Would you agree with that?

I would not say that is a lack of transparency I would say that you are going into a micromanagement road. I was developer in the past and to be honesty I always hated to create task under my user stories or report time. All the small details that the developers do to achieve the sprint goal is not that important. As long you have access to the sprint board and the developers are updating that according you should have a good view of the overall progress towards the sprint goal. Of course communication is important if you don't see activity in the board it worth a check in with the group to understand where you could help them move forward.