It makes sense to me that if an object needed to pass itself to an outside function, it would send "this".
I've seen some C++ that uses "this" anytime it accesses a property. Does that protect the author from some
sort of folly?

An example might be:

void Character::getObject(Object * obj)
{
	obj->next_content = this->carrying;
	this->carrying    = obj;
	obj->carried_by   = this;
	obj->in_room      = NULL;
	obj->in_obj       = NULL;
	this->carry_number += get_obj_number(obj);
	this->carry_weight += get_obj_weight(obj);
}

// VS.

void Character::getObject(Object * obj)
{
	obj->next_content = carrying;
	carrying    = obj;
	obj->carried_by   = this;
	obj->in_room      = NULL;
	obj->in_obj       = NULL;
	carry_number += get_obj_number(obj);
	carry_weight += get_obj_weight(obj);
}

if you make a local variable called carry_number or carry_weight then you use that it will assign the value to the local variable rather than the member of the object, unless you explicitly declare this->

Would enabling shadow variable in warnings prevent that? I've used / omitted this-> for my own readability's sake in various places but never gave consideration about a local variable named something in the member class (and haven't had that problem; yet).

I think it does… not sure.

For the most part, it's a stylistic thing. I find it "noisy", personally. The only time it's actually necessary is when your code is looking at a member variable for a class template who inherited from one of its template parameters. For example:

template <class Base>
struct Derived : Base
{
    Derived()
    {
        // Without "this->", the compiler must assume that foo_ is
        // a non-member variable, because it can't see it in the current
        // scope during that compilation stage.  With this->, it now knows
        // that it is a member variable from the inherited base class.
        this->foo_ = true;
    }
};

Or when there is shadowing, as was mentioned.

void Foo::bar(int x) {
 this->x = x;
}

I usually just use a naming convention that avoids the problem, by adding a _ suffix to member variables. Some people hate that, though, and some people hate using 'this'. :shrug:

At which time you can also change the names of the variables involved in order to avoid the this->. You can't do that with the case I showed.

Incidentally, I also add an underscore suffix. However, if I were a regular Visual Studio person, however, I'd probably use the time-honoured m_ as it plays more nicely with Intellisense.

Sure, that's true. But if you change names, you start running into somewhat silly cases like:

void Foo::bar(int otherX) {
  x = otherX;
}

or 'aX', 'theX', 'newX', etc. My preference is to leave variable names as clear as possible, and use 'this' to disambiguate.