textDocument/references is more strict but textDocument/documentHighlight delivers more information while being fuzzy

The result of textDocument/documentHighlight is defined as null or an array of:

export interface DocumentHighlight {
	range: Range;
	kind?: DocumentHighlightKind; /* one of Text, Read, Write */
}

and the result of textDocument/references is defined as null or an array of:

interface Location {
	uri: DocumentUri;
	range: Range;
}

The spec states:

However we kept ‘textDocument/documentHighlight’ and ‘textDocument/references’ separate requests since the first one is allowed to be more fuzzy. Symbol matches usually have a DocumentHighlightKind of Read or Write whereas fuzzy or textual matches use Textas the kind.

I don't understand why textDocument/documentHighlight is allowed to be fuzzy while actually delivering more information. It's result data type is richer and I would expect it to be the result of textDocument/references instead. Why not return DocumentHighlightKind in both?

Start with the textDocument/documentHighlight and textDocument/references definitions in the LSP specification, including the linked DocumentHighlightKind section. Compare the stated fuzziness and result shapes, then determine whether the distinction needs a rationale or clarified specification text. Done would be an agreed explanation or a documented specification change.