Why there is no reference of Sprint goal ?

Do you believe that when we consider the 'What' question at Sprint Planning, that Developers should only select PBIs that meet the Sprint Goal directly? What about bugs or high priority support action?

Whilst the Sprint Goal is absolutely a focus in Sprint Planning, it is not a restriction. There has never been a rule that the Developers can only work on or select PBIs that contribute towards the Sprint Goal.

It is my opinion that focusing ONLY on the Sprint Goal when answering the 'What' question is restrictive. In my experience, the Sprint Goal is the first consideration, but then we may discuss other work that is ordered high in the Product Backlog. To share an example, what happens if you accidentally spelt the name of your Product wrong on your homepage? You don't need a 'whole Sprint Goal' to fix that, but you can bet that the Product Owner is going to want that fixing in the next Sprint.

I agree with Ryan, in our product, we have the main goal or target of the sprint (sprint goal) but sometimes it's just something small, so therefore we pull other PBI's that have been ordered and refined that we can estimate that we can complete during the sprint, at times, having nothing to do with the overall sprint goal

Add me to the list of people who feel that only taking items from the Product Backlog that support the Sprint Goal is not the best idea.  For example, if you discover some new information while working on a Sprint Backlog Item that is going to increase the work needed to complete it, how do you compensate for that in the Sprint?  If you have items that are not related to the Sprint Goal, one of them could be removed from the Sprint Backlog to allow for the work needed to support the Sprint Goal.  Remember that the objective of the Sprint is to complete the work to satisfy the Sprint Goal, not to complete all the work that is in the Sprint Backlog.

Also by taking items not related to the Sprint Goal you are able to address ares of technical debt, introduce research spikes, fix defects that exist in production.  Otherwise those items will never be completed unless you dedicate a Sprint to specific items of this type and craft the Sprint Goal to support the work.

In topic one of Sprint planning, it is given the team discuss the Sprint goal. then in the next step, Sprint goal should be the reference for selecting the product backlog items into sprint backlog ? 

Why do you think that these topics are "steps"?

only taking items from the Product Backlog that support the Sprint Goal is not the best idea

I agree that all the backlog items in a sprint may not contribute to sprint goal. But my point is about the sprint goal itself.

Why do you think that these topics are "steps"?

The reason why I expect the topics in sequence is strategically the goal will be set before the planning. Apart from this generic reason, I was trying to connect the dots as below,

The product goal is long-term objective can be set before starting the product backlog emerges to define “what” will fulfill the Product Goal. Likewise, I am believing Sprint goal is the objective for a sprint and the backlog items can be added to meet the goal(of course the goal is negotiated based on how much team forecasts for that sprint).

Also a Sprint could be cancelled if the Sprint Goal becomes obsolete. In this case, whatever increments 'Done' thus far also will be void ?

It is not obligatory by guide but we have seen challenges when it is not in sequence. For example, a Scrum team takes backlog items for different features 'ordered' by PO then framing a sprint goal is becoming like a summary of different backlog items. 

I see now all these points boiling down again to the same discussion in other query I found here  https://www.scrum.org/forum/scrum-forum/5960/sprit-goal-selected-or-aft…

Here's what one of our team uses for sprint planning:



 

Checklist

1. PO proposes a Sprint Goal.
2. Select Features and PBIs that fit the Sprint Goal.
   
   1.Are all potential Features and PBIs Ready? (DoR).
   
   1.Do not pull in items that are not Ready.
3. Review the Bug list, what Bugs should be fixed?
   1. Are these Bugs Ready? (DoR).
   2. Do not pull in Bugs that are not Ready.
4. Review the Tech Dept list, what Tech Dept items that should be fixed?
   1. Are these Tech Dept items Ready? (DoR).
   2. Do not pull in Tech Dept items that are not Ready.
5. Review Velocity.
6. Review Capacity.
7. Calculate the Average Velocity and subtract time for Bug fixing, Tech Dept work and Capacity allowances.
8. Select the Features and PBIs that match the Velocity.
9. Review Test Plan (maybe later).
10. Does the Team have the people, skills and resources to deliver the Sprint Backlog?
    1. Plan the work.
11. Set Sprint Goal.

Do not pull in items that are not Ready.

Why compromise Agility? Sprint Planning allows additional refinement:

Scrum Guide: Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

In reality most PBIs should be made ready before a Sprint starts to make for an effective Sprint Planning event, but things change quickly in complex situations and there should be some flexibility for exceptions. Having a formal gate such as a DoR is an anti-pattern that sometimes impedes the Product Owner from maximizing value. I have seen Product Owners in tears because they had one additional PBI that emerged from the prior Sprint Review, and Developers refused to bring it into the Sprint because of the DoR.