Simply put, the PC and the mainframe are two different animals. Therefore you have to consider their designs and how the software needs to interact with it. The PC and mainframe are the same in the sense that there is an operator there, but with the PC, every user has operator status.
Therefore it becomes more incumbent to have good screen handling in the PC COBOL, because the average user will need to interact with it more. Now with the mainframe, the typical way things are done is that JCL is submitted in batch jobs where the COBOL programs would run unattended.
But what of the need for user interaction. Since you have multiple users on one system, you need to have a multi-tasking capable system there to handle multiple responses, multiple screens (sending and receiving), multiple accesses to hardware, and so forth. This is where things like CICS come in.
CICS stands for "Consumer Information Control System", which is a bad name for what it does, but does fit. It's a facility that handles all user interactions. It acts as a process started on the mainframe in batch, then the programs written for it act as processes within CICS. If it helps, it's best to think of CICS or any other product that performs the same function (like IMS/DC) as a multi-user interface.
Now as part of this multi-user interface, a way to describe the screens needs to be made. For CICS, that's BMS (or Basic Mapping System). You have to define the scripts some way, so there's a script language for that. Like you point out, it's no surprise that other vendors have gotten into the act of making visual interfaces for making screens (and I don't blame them, BMS can get very laborious and very rough sometimes if you don't plan the screens out first).
It's not a COBOL issue, it's a mainframe issue. Programs written in other programming languages on the mainframe can still run as processes under CICS, but they still make the same calls as CICS and still use the same resources.
Of course, to confuse the issue, there are other multi-user interfaces (like TSO/ISPF and CMS) where you can write straight programs and run them in those interfaces, but these are generally considered to be for programmer use (since they are more for OS function than user function), and not necessarily for general user use.
Hope that clears a few things up.
