다른 이유는 잘 모르겠으나 운영상 프로시져로 구현되면 불리한 점 두 가지정도만 지극히 주관적으로(^^) 말씀드립니다.

1. 개발 결과물은 그 형태가 무엇이건 형상관리(버전관리)가 매우 중요합니다.
시스템이 복잡해지고 커질수록 그렇습니다.
프로시져로 그 많은 소스가 개발된다해도 작업결과는 같겠지만, 개발 후 소스 등 산출물들의 형상 및 버전관리는 어찌 하실 수 있을지 거꾸로 물어보세요~~

일단 의견을 내신 분이 형상관리의 필요성, 중요성을 잘 모르시는 분이라면 그 분의 의견을 살짝 무시해도 좋을 듯 합니다...;

2. 형상관리가 되면 운영업무의 또 다른 핵심 개발지원 시스템인 App Mining Tool, 즉 소스나 모델의 영향도 파악 시스템의 도입이 가능해 집니다.
프로시져처럼 DBMS내에 소스가 존재하는 것은 형상관리의 repository로 관리하기가 곤란하여 일일이 열어보면서 수동으로 영향도 파악을 해야합니다.
(큰 시스템은 이런식으로는 영향도 파악만으로도 자체가 프로젝트 급이 됩니다.)
요새는 아주 적은 규모의 시스템 아니면 이렇게 관리하지 않을겁니다.

이 외에도 관리적 측면에서 많은 개발/운영 지원 시스템의 도입이 어려워집니다.

이 문제는 단순히 개발자의 Pro*C, 프로시져 관점이 아닌 약간 더 윗선에서 전체를 바라보면서 정책적으로 고려해야 할 필요가 있을 듯 합니다.

finecomp님께서 아주 잘 설명해 주셨습니다.
배치작업에서 SP로 하지 못하는 가장 큰 이유는 형상관리입니다.
그 부분이 해결이 된다면 장점이 아주 많습니다.
SP로 작성이 되어 지면 프로그램 소스는 DBA의 관할 안에 들어오게 됩니다.
혹시 문제가 발생하게 되면 PRO*C로 작성이 되어 있을 땐 개발자가 도움을 주어야 하지만 SP로 구현이 되어 있을땐 DBA가 즉각적으로 대처가 가능하구요,
그만큼 소스 보기도 쉬워 집니다.

finecomp 님 말씀대로 이 부분은 정책적으로 고려되어질 사항이라 생각합니다.

^_^답변 감사드립니다!

각각의 장담점 잘 파악했습니다..

사실 전 프로시져 쪽이였는데..

버젼에 대한 문제도 존재하는걸 전혀 생각하지 못했네요..

^_^두분 다 정말 감사드립니다.