That is one thing. This example from the post is another:

    var customerOrderGroups =
       from(customerList)
       .select(c -> tuple(
           c.companyName(),
           from(c.orders())
               .groupBy(o -> o.orderDate().year())
               .select(into((year, orders) -> tuple(
                   year,
                   from(orders)
                       .groupBy(o -> o.orderDate().month())
               )))
       ));

Yuck! I need to read that entire thing to have any clue as to what that produces or how I should go about using it. It is compact but it is not understandable. The "Magic" of Java is clean abstractions with no voodoo. PHP/Ruby programmers like their frameworks who hide code from the developer, which layer on complexity, and which "just work" (until they stop). In a proper Java project anyone can visually see, in any part of the program, what is attempting to be done and what is being linked up to what. A big portion of this is types.

    Account account = ...;
    List<Transaction> transactions = ...;

Is all you need to read from your example. If we were to expand your ideal to a function it would look like this:

   void someFunction(var customer) {
       var account = customer.GetAccount();
       var transactions = account.GetTransactions() 
   }

I can honestly tell you that it is impossible for me to know what will happen in this program unless I go through and look at every single code path that reaches this function. Once you have entire functions, or units of code, that are using `var` it becomes entirely unmanageable. Is a string getting into `someFunction`? What about a `Trader` or a `Banker` making it's way into there rather than a `Customer`? Would you know this was happening as both Trader and Banker implement .GetAccount()?

It's no surprise though that in the world of null-propagation haven that the language maintainers would decide to expand this class of problem to all object types! Why should the null primitive be the only thing that gets to ruin our day?

That code is much more scannable. The ability to scan code, to quickly glance at a method or a class and grok it in under 30 seconds is paramount. In large projects I've worked on any code that fails the 30-second test is immediately rejected at code review. Having to hover over every variable to see the types will make scanning such code in an ide a very tedious process. It will make most code review tools (that don't support such functionality) much, much less useful. I fear for the 30-second test and scanning code.

This is a poor argument for var. Competent Java programmers use the extract-to-variable keybinding (Cmd-Opt-V in my environment); it even guesses the variable name correctly.

Yes? I'm fairly certain you used their account to get an ordered list of their transactions.