They are stating that since you only use one dot, you are not breaking the Law of Demeter here. I think this is incorrect, because you are still going through customer to go through address to get the invoice's street. I primarily got this idea from a blog post I read:

The Law of Demeter is a guideline for doing software design, not a stone tablet. Most of the time it is correct, but there are instances where it is inappropriate or overkill. Sometimes you are dealing with third party libraries that you can't change, for example.

It is more useful as a tool to make you think about the level of coupling in your code in relation to the overall design. While just counting the number of periods in the train-wreck method call is a neat way of quantifying it, perhaps if you are writing some software that analyses code to pop up thought bubbles in your IDE, it isn't a panacea.

In the example above, it should make you think about the object responsibilities and why you want to ask an invoice for such a low-level detail as one line of the address. Why not ask it to format the invoice address for printing, or give it a method that sends the invoice as an email.

In the paperboy example, maybe the Paperboy ought to call the obtain_payment method on Customer, passing an invoice. The Customer can then call get_total on the Invoice, look in his own Wallet to see if he has enough cash, and if not he can opt to pay the Papershop directly with his DebitCard or give the money to the Paperboy, possibly recording the payment in some kind of Account at the same time.

The point here is not about the number of dots - it is about how much the Paperboy object needs to know about internal implementation of the Customer. He doesn't care if he has a wallet, purse or bank account, he just wants his money. This allows you to change the implementation of the get_payment method without touching the code in Paperboy.

Thinking about the level of abstraction in your methods, are they high-level, mid-level, or real low-level nitty-gritty stuff? If you find a method that's calling a method that's significantly above or below it's peer group, then you should be asking yourself questions about why. For example the do_the_gardening method on the CEO object has a different implementation from the one in the Gardener object. We wouldn't expect the CEO to be interacting with the Spade object directly