Sprint Backlog estimation

 IN other words, can we afford to have any item in the sprint backlog that do not have a reasonable estimate after the sprint planning meeting?

That would be a question for your Scrum Team to decide. Remember the purpose of Sprint Planning as described in the Scrum Guide.

Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?

Another quote from the Scrum Guide, also in the section describing Sprint Planning.

The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

There are also 4 mentions of "estimate" in the Scrum Guide, all contained in the section on Sprint Planning.  I suggest you read that section again.

But ultimately, this question has to be answered by your own Scrum Team.  But I would also ask this when you ask them your questions. Are we adequately describing the work needed to fulfill the Sprint Goal and deliver the Increment if we continue this practice?

Is it mandatory that all Sprint Backlog items have a definite estimate after the Sprint planning meeting?

Do you think existing items ought to have a clear estimate before they are considered “ready” for Sprint Planning? If not, why not?

Prasanth, I guess you're asking (or at least implying) two different things.

First, sprint planning serves other purposes - while you can, of course, discuss issues and get estimates, planning is aimed at identifying a) what is going to be build and b) how it's going to be built (in terms of tasks, at least for the next day or few days). So the primary purpose of a sprint planning is what + how, with a Sprint Goal being drafted, goal that would help everyone (but mainly the development team) and secure the right focus. 

Estimations are usually gathered via backlog refinement sessions, which you'd want to implement throughout sprint.

Second, during sprint planning it is usually a good practice to have items already estimated (with the help of refinement sessions, as pointed out above). But there's nothing preventing the team to discuss items and get ad hoc estimates.

Note the team can select any stories (including not estimated ones!) they reasonably believe (forecast) are doable within the sprint. They can even select pull items that are so new/exotic/confusing/complex/etc, that they can't estimate, but rather create a spike (say, as a subtask), dedicate 3 days for investigation on it, and take it from there.

Thank you Eugene, this helps. My question was only on the estimation part.