There are definitely a lot of styles of programming that allow to be much more forgiving, turning the actions you describe as a noop. I generally implement code that way as well. However, if this were implemented using a state machine, in general, an illegal state change would throw. So it's highly dependent on the solution chosen.
That said, if you feel like this exercise would be better off with less throwing, perhaps it's a good idea to also open an issue on problem-specifications and see how this is implemented cross-track before we commit to any changes here.
Practice exercise 'bank account', too many throws #1930
I've noticed that there are a lot "error" cases in this exercise. IMO these two tests are superfluous : "close already closed account throws error" and "open already opened account throws error".
Indeed, IMO there is no functional problem with closing an already closed account. In a real world, I try to go by the "Define errors out of existence" principle from "A Philosophy of Software Design" by John Ousterhout. In this chapter, the author points out that throwing errors unnecessarily increase the complexity of the software. We shouldn't be throwing errors if there is no real problem.