Yes, so the function can change thing.

In general, it is best to put the behavior on the object itself. In other words, prefer this:

class Thing {
public:
  void do_stuff() {
    ...
  }
};

…to this:

void do_stuff( Thing & thing ) {
  ...
}

However, both examples are perfectly valid and usable. One good example of a non-member non-const reference parameter is stream extraction operators. This Stack Overflow question goes into more detail: Does anyone actually use stream extraction operators? The general idea is this:

operator>>(std::istream &, Thing &)

The function cannot exist as part of the Thing class because the left-hand is not an object of the class. It also needs to modify a Thing object so the reference cannot be const.

There are reasons why you might want to change things in place. One reason might be performance: it’s expensive to make all those new objects for output.

There are reasons why you might write things in a more functional, immutable style. One reason is referential transparency. Another is easier and more reliable concurrency and function composition.

Everything is a tradeoff. As with most things in software development, the right choice depends on your specific needs. C++ is a multi-paradigm language; it allows you to make the choice yourself.

Yes, some times it is very convenient to be able to locally modify a pass-by-value argument to a function. For example, the argument might be a reference to a node of a linked list, and within the function you may want to traverse the list, so you will want to be doing node = *(node.next);.

So, ill-advised? definitely not, in my opinion.

There exist languages which do not allow you to modify function arguments, (Pascal, I think?) which forces you to make a copy of the argument into a local variable in order to modify it, and then the problem is that both the copy and the original argument are in scope, so further down in your code you may mistakenly read the argument instead of the variable. This kind of mistake is arguably more likely than an inadvertent modification of the argument. So, by allowing the argument to change, you eliminate the variable, and therefore the possibility of such a mistake. (I will not even bother with the performance issue, it is negligible, and even optimizable by the compiler.)

As for the possibility of mistakenly modifying thing, this is what I have to say:

In my experience, about 90% of the member variables, parameters, and local variables that we declare are effectively const. (final in java, readonly in C#.) This means that although we do not explicitly declare them as const, we treat them as const: we never change their value after initialization. Therefore, I hope a language ^(*1) will be created one day in which all “variables” will be const unless explicitly declared to not be const with the use of a special “non-const” (mutable perhaps?) keyword. This way, in the rare event that a variable is expected to change, it will be immediately obvious in its declaration, and the compiler will even be able to issue a warning if you declare something as mutable and yet forget to change it. This will, of course, also have the benefit of preventing you from unintentionally modifying your thing if you have not declared it as mutable.

_{(*1): an imperative language, since one might point out that functional languages already do that.}

Yes, as others have said, to modify.

One very compelling reason to do so is polymorphism. References are polymorphic, but objects may slice.

Another is to call a non-const member function on an object.

An example:

class A
{
    public:
    virtual ~A() = default;
    virtual void someMethod() { printf("A::someMethod()"); }
};

class Subclass: public A
{
    public:
    void someMethod() override { printf("Subclass::someMethod()"); }
};

//always prints "A::someMethod()" because the object is sliced
void do_stuff_wrong( A thing )
{
    thing.someMethod();
}

void dont_do_stuff( const A & thing )
{
    //thing.someMethod();// compilation failure.
}

// do stuff can legally call someMethod() which is not marked const
void do_stuff( A & thing )
{
    // Yay! it calls out polymorphically
    thing.someMethod();
}

In this examples