Why estimate by product and not by task?
What are the advantages of estimating a story considering its total construction instead of estimating by tasks that make up the story and then adding them to have an estimate of the story?
None. My concern would be why Developers thought they had to make a false and unduly prescriptive choice about their estimation approach.
I agree with @Ian. The team should decide how estimation works best for them. There is nothing in the Scrum Guide that addresses how a team estimates. In fact, the word "estimate" is not even in the current revision. The only tangental mention is this statement.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
To know if something "can be Done by the Scrum Team within one Sprint" implies some type of estimation.
Estimating by story points is better than by task.
Because
1. story points is estimate by the Scrum team not just by the developer.
2. Maybe first-time story points is not so accurate at one Scrum team, but it will become more and more accurate later with the increase of teamwork times.
3. if we estimate by story point(product), we can talk it with po/Scrum master/PM/Clients, and estimate the story scales.
Thanks to everyone for your replies. They helped me a lot.