제가 올린 글에 대한 답변을 스스로 적어보겠습니다.

1. Transaction에 대한 부분에 대한 나름 결론입니다.

일단 로그로 관리하는 방법 이외에는 대안이 없는 것 같습니다.
APM과 같은 툴에서는 업무 트랜잭션에 대한 부분을 볼수 없기때문에 대부분의 금융권 프로젝트에서 사용하는 로그방식으로 모니터링에 대한 정보를 수집해서 보여주는 것이 가장 무난할 것입니다.
특정 업무 Transaction이 문제가 생겼을때 그 뒤에도 계속 발생될 수 있는 문제라면 그 서비스를 사용할 수 없게 서비스 앞단에 조건처리를 달아주면 전체 서비스를 중단하지 않고 응급복구할 수 있는 시간을 벌 수 있을 겁니다.
물론 DataBase나 시스템적으로 문제가 생긴경우라면 별 소용없는 기능이 되겠지만요...ㅎㅎ

2. 구현에 대한 부분은 다양한 케이스가 있을 수 있는데요. 제 짧은 관점으로는 다음과 같이 생각됩니다.

 2.1 유지보수관점에서 각 개발자들의 특성이 묻어나지 않는 개발환경제공 가능한가?
 -> 이 부분은 각 티어별 분리와 패턴적용 그리고 공통모듈의 제공으로 어느정도는 가능할 것 같지만...
    개발자들의 수련정도에 따라 어찌할 수 없는 부분이 발생할 수 밖에 없습니다.

 2.2 Java로 Batch Job 구현시 성능은 Pro*C에 대비해서 어느 정도인가?
 -> 음...Pro*C로 배치 프로세스를 구성하는게 개발생산성 및 유지보수 관점에서는 최악의 선택이 될수 있을 겁니다.
    일단 기존에 개발된 서비스 컴포넌트를 사용할 수 없으니 처음부터 다 만들어야 하고, 현재 Pro*C를 할 수 있는 엔지니어가 시장에 얼마나 있을지...내부자 교육으로 어느정도까지 가능할지도 의문

 2.3 UI, 컴포넌트, 클래스, DB Table까지 포함된 비지니스 로직을 정의하는 산출물이 가능한가?
 -> 이부분은 캐빈님이 좋은 아이디어를 주셨는데요~ 각각 연결되는 부분을 매트릭스 테이블 형태로 관리를 하는 것입니다. 만들때 노가다 작업은 피할 수 없겠지만~만들고 나면 설계자의 의도를 개발자가 파악하기 편할 것 같습니다. 예전에 DB Table과 Function간의 매트릭스 테이블은 가끔 보긴 했지만.

 2.4 Spring을 사용하지 않고 EJB + POJO 개발 방식을 사용할 수 있는가?
 -> Business Object 패턴으로 이 부분은 해결하면 될것 같습니다.

3. 기타의 업무시스템을 굳이 J2EE Platform으로 만들어야 하는가?
  가장 무난하고 많이 쓰이는 기술을 쓰는게 안전하다는 IT 의사결정권자들이 선택하는 부분을 왜라고 따지는건 무리입니다. 언젠가는 다른 플랫폼이 나올때고 그때마다 업무시스템을 바꾸어주어야지 우리 같은 사람들이 먹고 사는데 지장이 없지 않을까요...^^;