I think if you keep in mind we're talking simple and not easy, then it's sort of like "of course". And there's definitely a sort of elegance in a simple design, like how Apple does hardware, that still manages to "get the job done". So in that sense it's more of a considered constraint than neglect.
But I think there's also a danger of this becoming cargo-culted/dogmatic to the point where's it _is_ the messy, short-sighted solution. I remember many years ago working at a company that adopted XP and TDD and the whole "write the failing test and then the simplest thing to make the test pass". Well-intentioned but with some experience you quickly realise that sure, just returning a hard-coded value will make the test pass simply, but I _know_ there's more requirements coming and that code's going to have to change. So to with system design, I suspect there's also a case for experience telling you that the changes are coming. Maybe this still fits into the "possibly work" part.
The other thing I've seen in my time is that you don't always get the capacity to come back change the design later. So while it's great (and probably bordering on being clever for clever's sake) at times to do the simple thing, hedging your bets in terms of how a system will have changes piled on can often be a good move too.
I think that the main issue with these kind of concepts is they always sound great on the face of them but in the real world it's never that simple :P
But I think there's also a danger of this becoming cargo-culted/dogmatic to the point where's it _is_ the messy, short-sighted solution. I remember many years ago working at a company that adopted XP and TDD and the whole "write the failing test and then the simplest thing to make the test pass". Well-intentioned but with some experience you quickly realise that sure, just returning a hard-coded value will make the test pass simply, but I _know_ there's more requirements coming and that code's going to have to change. So to with system design, I suspect there's also a case for experience telling you that the changes are coming. Maybe this still fits into the "possibly work" part.
The other thing I've seen in my time is that you don't always get the capacity to come back change the design later. So while it's great (and probably bordering on being clever for clever's sake) at times to do the simple thing, hedging your bets in terms of how a system will have changes piled on can often be a good move too.
I think that the main issue with these kind of concepts is they always sound great on the face of them but in the real world it's never that simple :P