I've seen this kind of pattern usually when working with web services.

Imaging the following piece of code:

public bool RunCommand()
{
    
    // .. Some logic ..
    
    return true; // success
    
}

Basically we have a method in a class that executes some logic, if this is successful it returns a true, if not a false. At first you would say this make sense, right?

It kind of reminds me the days when I was learning C :)

But this is just over-complicating things. Any client of this method will have to add a check.

if(RunCommand()) {
  // everything good

// Show user success message

} else {

// error!

// show user something went wrong

}

Why not just assume that the method is going to be execute successfully? If not just throw and exception! Then just handle that exception. Simple!

Just adding the true/false return for success/error is basically re-implementing exceptions. Well, it's even worse. Exceptions are explicit, they mean that something went wrong, they even have a custom error message. A boolean just means that.. a boolean: true or false, it's open to interpretations. When we get a false it could mean anything, no error message, no custom exception.

Also returning values from command methods is a bad practice. You should have two kind of methods: querys that return values but don't change anything in your system and commands that change something but return nothing! This is known as CQS or Command and Query Separation.