It's in deep nesting like that that such an operator really comes into its own. If you only use it for single cases, it really isn't worth it.

In the article the 'problem' code is:

    if u && u.profile && u.profile.thumbnails && u.profiles.thumbnails.large
      do_something_with(u.profiles.thumbnails.large)
    fi

which repeats u 5 times, and the entire u.profiles.thumbnails.large twice!

which would be replaced by only asking once.

even worse (although somewhat clearer, perhaps) is what I've occasionally seen:

    if u
      if u.profile
        if u.profile.thumbnails
           if u.profile.thumbnails.large
             do_something_with(u.profile.thumbnails.large)
           end
        end
      end
    end

And even the super verbose version there still can raise exceptions when you get slightly mad data - say you decode some JSON which has u.profile.thumbnails as "null" (a string) rather than actually a null. asking

    if u.profile.thumbnails

will be true - but when you request u.profile.thumbnails.large, you blow up.

You can achieve similar effects using only exceptions, but there's a good argument for using exceptions only for exceptional circumstances.

    begin
       do_something_with(u.profile.thumbnails.large)
    rescue NoMethodError #or similar
       # oh no!
    end

which (alas) also will catch all noMethodErrors in do_something_with. So you then end up with

    begin
      tmp = u.profile.thumbnails.large
    rescue
      tmp = nil
    end
    if tmp
        do_something(tmp)
    end

which is super ugly.

I may have got details wrong - not being a rubyist, but I think this is the general gist of where a nestable operator makes much much cleaner code, which catches more errors.