In practical security, closing a buffer overflow, sanitizing inputs, and proving code paths are not "obstacles".
I think you're being a bit picky over wording, an "obstacle" is just something which makes it harder for some to break your system, examples of which are closing buffer overflows and sanitizing inputs.
You could, possibly, use it as an argument against engineering, but I think you'd be wrong. The same as someone arguing "we're all going to die anyway so lets get it over with now" is wrong: it means that you have to make the most of what you do have.
This isn't just pickiness. This is two totally conflicting mindsets about security. I'll be ungenerous and say that mine, which rejects the concept of obstacle courses, is the practitioner's mindset.
We don't let things ship when we know they have exploitable vulnerabilities. We recognize that there are known unknowns and unknown unknowns, and we try to mitigate the former. But the known knowns? Come on. Just turn SSL on. The Javascript rewriting hack is not hard.
I think you're being a bit picky over wording, an "obstacle" is just something which makes it harder for some to break your system, examples of which are closing buffer overflows and sanitizing inputs.
You could, possibly, use it as an argument against engineering, but I think you'd be wrong. The same as someone arguing "we're all going to die anyway so lets get it over with now" is wrong: it means that you have to make the most of what you do have.