Estimation vs Sizing & Effort vs Duration

Please correct me if I am wrong, but as far as I understand, as Scrum Guide 2020 we should probably not use the word "estimation", in favour of the word "sizing". How would the two really be different? Personally, what I like about "estimation" is the uncertainty intrinsically hidden behind that word. 

I don't see any differences between "estimate" and "size". In fact, one dictionary definition of "size" as a verb is "estimate or measure something's dimensions". The authors of the Scrum Guide have chosen to use "size", so that's the term that would probably be used in training courses and on certification exams and in similar contexts. In a team's daily practice, I don't see any readily obvious shifts in perspective from using one term over the other.

When sizing work in the software development domain (does it actually depend on the domain?), I am struggling a bit in understanding the difference between "work effort" and "work duration", as currently I see them respectively as "how hard/complex is to perform a work - you do not know how much time it will take if it is hard" and "approximately time duration". Is my understanding correct, or should I see it differently?

Effort is how much energy or strength you'd need to complete a task. Duration is how long it will take. Complexity is related to how involved or how many different aspects a piece of work has. There may be relations between these three things, but they aren't necessarily directly related.

A piece of work could be highly complex with lots of very small, intricate pieces that need to come together. However, each piece could be completed quickly and without much effort. Complexity is high, but effort is low and duration is low to moderate.

A different piece of work could have low complexity, meaning there aren't a lot of pieces to do, but what is there is very time consuming and requires a lot of manual effort. High effort and duration, but low complexity.

A third piece of work could have low complexity and take a lot of time, but the work is mostly automated with minimal manual effort. This is low effort, high duration, and low complexity.

Generally speaking, adding complexity and/or effort also adds duration, but that's not necessarily true.

In certain contexts, items can be "sized" by refining them so they are of more or less of the same magnitude. The service delivery of ticketed work is one possible example. Reasonable forecasts might then be made based upon observations of throughput.

You could think of this as either a kind of estimation or as an eschewal of estimation altogether (c.f. #noestimates).

The definition of size, "estimate or measure something's dimensions”, mentions estimate, though I believe it to be more about “something’s dimensions”. When you are sizing, you are estimating the dimensions of the work.

By thinking of size as dimensions we can factor in various dimensional aspects such as risk, repetition, complexity etc.

How long it will take a person to tackle work of a particular size or dimension is likely to differ person to person, but we can usually find common ground on the dimensions of the work.

By using “size” it also leaves it open so teams can decide how best represent estimated PBI dimensions be it using t-shirt sizes, Fibonacci sequence numbers, Simpsons characters, fruit or whatever works for them.

I wouldn't get too caught up in the wording but there is a lot of baggage with the term estimate - often implying time. I think words are a tool - their intent is to convey understanding and meaning.  

Size is more along the lines of "will it fit in a certain container". Will it fit in a sprint?

Estimation can be used to infer that the work will take X amount of time and therefore these many sprints or man hours.  A predictive mindset. 

Like others have said, the heart of this is to help people enable empiricism and learning rather than precision and conformity.

I wouldn't get too caught up in the wording [...] their intent is to convey understanding and meaning

Fully agree! Let me please add a bit more of context: I've asked myself these questions about size vs estimation now that, as a Scrum Master, I'm involved in "teaching" some aspects of this delicate topic and I got some interesting questions by the team. Personally, I probably value wording a bit too much, maybe because I perceive it as fundamental in communication: in everyday life, I believe it is so easy to be misunderstood as the speaker or the listener do not share the same understanding of a given word - which could results in misinterpretations or longer, yet interesting and valuable discussions, which in my personal opinion, could be avoided ("waste").

Thank you very much everyone for all your great and precious answers on this topic!