The "can do" attitude is fine (I have it, and always have), but we need to inject an additional dose of user-reality into analysis of from where the problem comes.

Part of the reason you get stonewalling has to do with failed requirements planning. Consider a developer who has spent months digging out requirements from a user group, done multiple run-ups of interfaces for them to test, and released a locked version of the business tool. A day later, one of the very same users begins making requests. Emotional human response to that aside, the suspicion is often that such a request means the requirements component was a farce on the user side. This is especially hard for a developer who puts great effort into doing things well and right, because it is a sign that the users did not deliver equal effort. The resistance in those cases isn't justified, but it does come from a real place: the concern the feature-add request is as ill-thought-out as the effort for requirements was. No one wants to do the same work multiple times just because the other side couldn't be bothered to communicate real needs. I'm not implying this is always the case, but it is an example of why the problem happens. Right now, I'm trying to rescue a project by a contractor who got trapped in this "new requirements" loop, and looking at their performance and documentation I can't fault them alone. A legitimate effort was stymied by the user view that an initial half-assed effort on their side could be offset by add-ons ad infinitum.

Another cause of the "technical barrier" attitude is often driven by the user-side (again, not really justified, only explained). That is where the user group consists of some users who have the power to make change-requests, and override others, but have no qualifications to do so. I recollect an awkward situation many years ago, when a time tracking application built by a company I consulted for was being driven change-to-change by the guy signing the cheques to pay for it. After a while, the only way to put the chap off changes was to start telling him they were technically dangerous, etc. The application in question worked to the relative satisfaction of all other users on the day of release, and some of the manager's changes were positive, but after a point they became vanity issues. (e.g., Lowly Fred asked for this and I'm tweaking it so it is my contribution.) In a circumstance like that, the developer has to make a difficult choice to protect core functionality or pursue the paying gig. As a businessperson, concern for the client's end-productivity should trump all.

A final explanation of the attitude problem comes from the all-too-common situation where the user requests are heavily weighted on superficialities. It seems these days, many of the projects I end up having to wrangle after the initial build, are completely stuck because somewhere along the way the colour of some screen element became of such concern no one was watching functionality. I recently was offered a save on a commercial website redesign that was eight months behind when the team working it was fired. I assessed it and ended up passing after two meetings, because I spent a total of eleven hours (paid, thankfully!) listening to the user group discuss irrelevancies. I tried to steer them with the fact they had a non-functional solution (core functionality was missing entirely), but they were so stuck on the colour scheme, placement of specific buttons, etc., it became obvious the bulk of the problem lay in that. I could see why the developers they fired were starting to use the "technical barrier" card with them. (Though I can also say the real issue was no management on the web development team's side.)

So, sometimes the attitude is coming from a real place, and the frustration that attends it is certainly easy to grasp.

At the end of it all, as well, we have a problem in the industry that exacerbates the issue: dependencies built on promises. How many times the last few years has an underlying technology actually been a barrier because it was late-delivered, had some show-stopping bug, etc. Developers are increasingly being handed more fragile tools by major providers, often too soon in the cycle and lacking stability, which makes delivering end-products tougher. It's not an excuse for the attitude, but it does seem to support the trend toward putting off the user requests as technically unsound -- because younger developers will do to their users exactly what the tool providers do to them. You need look no further than the fact MS still has no SP3 for SQL Server 2005. Granted, it's a slightly skewed example, but how can one explain the cumulative update stream but no SP, unless you invoke a phrase like, "technically, wrapping them in a SP...etc."

Anyhow, that's a slightly different perspecive from someone who is primarily a systems architect these days (whatever that means).