Extraction and expansion solve different problems
HKDF is a concrete extract-then-expand design. Extract processes initial material into a fixed-length pseudorandom key; Expand derives output of the required length. Handling the input distribution and producing purpose-specific material are different tasks.
A key-exchange result need not already be a suitable uniform symmetric key. Some uses with an appropriate pseudorandom input can expand directly, but omitting extraction depends on those assumptions rather than the desired output length alone.
References: [1]
Salt and context labels have different roles
HKDF salt generally need not be secret and helps independence across sources and uses; it is not the secret input material. Expansion info binds protocol, algorithm, role or other context to avoid accidental reuse across purposes.
Directions and handshake versus application phases can use distinct defined labels. Their encoding must also be unambiguous: arbitrary string concatenation or requesting more output does not by itself establish safe separation. These parameters belong to protocol design.
A longer derived key does not increase password entropy
Extraction concentrates existing entropy rather than turning a small guessable input into an equally long unpredictable secret. RFC 5869 explicitly notes that HKDF lacks a dedicated slowing mechanism for password dictionary attacks.
Password-oriented designs consider salt and the time and memory cost per guess. Memory-hard functions such as Argon2 expose memory, pass-count and parallelism parameters that must be assessed with resource constraints. Output length, input entropy and guessing cost are separate quantities.