But even if you do something objectively wrong, it can still work out anyway. Look at every Perl script written by non-programmers. Horrifying mess of bullshit, and you try to read the code and think this shouldn't even be parseable, but somehow the script works.
There is no right or wrong, only working and not-working.
If someone has written their own bubble sort to sort a list of numbers and you replace the custom bubble sort with a built-in sort - there really aren't tradeoffs to consider. Your method will be faster, easier to understand, more robust. Their method works, but is strictly inferior.
Actually, speaking as a mediocre programmer who got in to management and now only writes code for fun side projects, there are lots of times when I'd prefer a less-performant function that I understand to a more-performant-but-opaque builtin. What if the sort only handles 100 items but I need to be able to change its internal behavior? I'm a lot better off writing my own slow sort than trying to modify one written by a 10x Rockstar Developer whose code I barely understand.
For the same result, within the same accepted parameters, the 'inferior' method is really identical, with no tradeoffs. By measuring the result rather than the design, you see the true value rather than the theoretical value.
If you only need to move a 60lbs bag of sod across the yard, carrying it yourself, using a wheelbarrow, and using an F-150 Lightning all have exactly the same result and none is inferior. They can all be done in the same time by the same person with no real difference. It's only when the parameters change, like moving 400 bags of sod, that the first two require tradeoffs.
You're assuming that the "result" data structure is only a single boolean, is_task_done. That's not how most things work, GP's bubble sort will pretty damn well show up in locked-up UIs and injured-dog-slow bottlenecks, that's as observable as the Sun at 9 AM. That would happen pretty fast too - don't delude yourself with "Move Fast And Fix Later" with quadratic algorithms - 1000 squared is a million, and at 10000 it is a hundred millions.
>carrying it yourself, using a wheelbarrow, and using an F-150 Lightning all have exactly the same result and none is inferior
Off course not, the method used would show up in your health and exertion data, your fuel costs, the amount of noise and heat you emit while doing the work, etc... Every single way of observing a boolean is_bag_moved result can also be used to observe a metric measuring those things, and thus determine the method you used.
You're trying to defend an extremly strong claim : If algorithms A and B gives the same output in memory, NOTHING else matters. Here's an concrete example, consider the following sequence of algorithms:
Algorithm 0 : Print("Hello")
Algorithm 1 : do {Nothing} then Print("Hello")
Algorithm 2 : 2.times do {Nothing} then Print("Hello")
...
Algorithm N : N.times do {Nothing} then Print("Hello")
This is an infinite sequence of algorithms that all have exactly the same behaviour in a time-space agnostic manner. Would you say every algorithm in this sequence solves the proplem of printing "Hello" exactly as well as every other algorithm ? If yes... interesting. If no, then your original claim is false as-is, it needs qualifying with what observable behaviour means, as this example shows, it's a difficult notion to exactly define, a naive definition of "Everything that can be observed in computer memory or on screen" would leave you open to ridicilous conclusions.
When I was a Perl programmer, in our shop we amended the motto "There's more than one way to do it" to "There's more than one way to do it, but most of those ways are wrong."
The Perl community themselves eventually extended the motto to "There's more than one way to do it, but sometimes consistency is not a bad thing either"
There are a lot of objectively wrong ways to do something. But among all the right ways, there are trade offs.