Without reasonable efficiency, nobody would want to reuse your code. In fact, one of the hallmarks of reusable code is that it is efficient in a wide variety of circumstances; frequently the author of an API cannot predict what it will be used for, and thus must at the very least avoid pathological inefficiency when possible.
> I was not thinking about performance, about the efficiency of what I wrote, at all; I simply did not want to think about it at the time.
Bad software happens when you don't think about the efficiency of what you're writing at all. This perspective is completely detached from reality; in the real world, your code runs on a real machine and does real work. Sure, in some circumstances it's entirely appropriate to write inefficient code, but that's a decision that should be made after an assessment of the problem at hand. To intentionally ignore efficiency as a matter of policy is to ignore the facts of reality.
At the very least, you need to consider the performance impacts of the data structures you use. In most modern languages, it's not terribly difficult to use e.g. a hash in place of an array, and in the right circumstances it can make the difference between usable and unusable software. I can't even count how many tools I've used that, due to a poor choice of data structure, could not scale beyond the small data set that their authors tested them against, and were thus useless beyond a very limited scope.