That's certainly valid that proper organization is far more the key to good code than the use of any language - my comments should not be taken as an ad for Java or any other specific technology.
That said, certain language features lend themselves to good organization much better than others. Where SQL faces challenges is that (1) it's mostly a declarative language using set calculus, which (again, in my opinion) makes it ill-suited for non-trivial business logic, (2) because of the aforementioned, it can't be hooked up to a debugger in any normal sense, making maintenance and troubleshooting that much harder, (3) it's a separate "codebase" and technical competency than the "main" codebase (whether it's in Java, C#, Ruby or whatever), thus creating a competency barrier that must be crossed every time work needs to be done on that code, (4) it's not stored with the main codebase, but as a form of data, raising the issue of out-of-sync deployments with the app servers, and (5) far fewer developers know it well enough for complex uses than typical app-server languages, making staffing difficult.
Finally, I have personally always found large codebases much more manageable when written in a statically typed language (which SQL is obviously not). Not wanting to spark a flame war with Ruby or PHP fans, though, I will caveat my statement that those languages are also much better suited for business logic than SQL's declarative style is.