You appear to be arguing that an "unused" return value is a wasted opportunity to provide the caller with more information. I would instead argue:
Providing a return value adds one more thing that users of your API have to learn about and keep track of.
Providing a return value that the caller needs to check (as is typically the case with a success/failure boolean) introduces the possibility of the caller forgetting to check that return value.
So returning something rather than nothing is not automatically a win-win. Whether it's the right thing to do depends on other considerations.
Is it possible to implement this method in a way that makes it impossible to fail? (ignoring cosmic radiation and mice chewing on the wiring and so on) Then return nothing. Users like it when things can't possibly fail.
Is the failure unusual? Then consider throwing an exception instead. The debate between exceptions and return values is far too complicated to get into here (see gnat's proposed duplicate), so I'll just point out that return values will silently fail to do anything if the caller isn't checking for them, while exceptions are "impossible to ignore".
Is the failure likely to indicate a bug in the calling code? Then consider assertions or exceptions that provide some helpful error message to the programmer that made the mistake.
In this case you could potentially answer yes to all three questions. You can prevent
bal from becoming negative in your other methods. You can probably assume that most of your clients will have a positive balance most of the time. You can argue that the caller should always check
charge(). This is where you to have to make a subjective judgment call.
Returning booleans for success / failure enables an (optional) extra layer for exception handling.
If the possibility of failure is unavoidable, then I would agree that you should do something when a failure happens other than silently ignoring it. But there are many ways to notify the caller of the issue or at least enable the caller to detect the issue, such as throwing your own exceptions, asserting on the failure, exposing the status of the account via another method, or returning an enum of various error codes. Returning a boolean is just one of many options. Sometimes it's the best option, but not always.