There are some fundamental changes to the way we look at capacity management.
please check below blogs which helps you in understanding the change :
Your first screenshot and point.
Contention and demand are not related as such. You can have low demand and high contention or visa versa.
Demand is how much (in this case) cpu the host is asking for so it can be over 100% so the CPU utilisation of all of the VMs is 2.76% more than physical available in the host
Contention is generated when there are too many vcpus to physical cores and the vCPU's have to contend with each other. The lower the better
It all depends on you and which metric you want to colour. In this case it is contention
the difference between the first two screenshots depend on the refresh interval. When you load the dashboard the 300 seconds start on the heat map. When you click the host the graph will show you the latest collected stat and its 300 second countdown will start. So you can get a situation where the chart is more unto date than the heatmap. on the chart you can mouse over the 5 mins before the current and it may be the same as the heatmap.
Also you could have the heatmap more up to date that the chart if you load the dashboard and dont do anything for 2 mins and the select the host the chart will update and start its 300 second countdown and the heatmap is already half way through its refresh cycle.
Your 6.5 is 100% of usable not the total as you are taking 22% off the total to get usable. In the 6.7 it is demand of the total. to get a closer comparison in the 6.5 you have a total of 481.1 GHz and a peak of 459.5 GHz leaving approx 9.5% free
I am not 100% sure what 6.5 uses for demand based capacity model but if you expand the cpu to you see the graph you can see what it is using.