Not a kata suggestion, though it is a good effort ^^

Similar pairs would imply some approximate matching rather than exact whole word matching.
Perhaps ignoring case by mapping to lower case:

var seenWords = Arrays.stream(words).map(String::toLowerCase).collect(Collectors.toSet());

But similar pairs is also not quite right -- more like "count duplicates".
Otherwise the similar pairs eg in
{"Volvo", "Volvo", "BMW", "Mazda", "BMW"}
would be 2 -- a pair of Volvos and a pair of BMWs.

And how many pairs are there in { "Volvo", "Volvo", "Volvo", "Mazda" } ?
Actually 3 - there are 3 ways to pick a pair of Volvos from the list 😆!

Every string is added only once. If you look at the diff, you can see why this works: Every string that can not be added is counted, because the set contains it already. The difference of the lengths is the same value as counting strings that can not be added, because the sets contains them already.

where do you check if the strings are similar?
you add them and subtract the lengths

That is interesting, seems like there is some additional overhead from using a stream as opposed to simply using a loop and stringbuilder

COBOL translation.

I have used Java Microbenchmark Harness to compare the throughput of the best voted ("Best Practices" and "Clever") solution with the throughput of a solution that does not use streams.

The result is:

Benchmark                              Mode  Cnt        Score        Error  Units
Main.benchmarkBackronym               thrpt   10  2147315,687 ± 165121,568  ops/s
Main.benchmarkBackronymBestPractices  thrpt   10  1250604,528 ±  73148,180  ops/s

If anyone is interested in the details, here is the JMH project on GitHub: https://github.com/rico-ding/backronym-micro-benchmark/