It's hard to answer "z/OS vs Linux on z" generically, because there's use cases for both. But perhaps the most generic answer I can give you in favor of Linux is: familiarity.
z/OS has a long history. It's predecessor, OS/390, dates back to the 1990s. Before OS/390, there was OS/360 which dates back to the 60s. Back then, IBM was first to market on business computer processing. (That was the only computer processing.) Major industries, like financial, insurance, and airlines, poured their infrastructure into mainframes, because it was the only name in the game. IBM prides itself in assuring its customers that the COBOL code that ran your business back in the 80s will still run today on z/OS 2.1 (the current version of z/OS). Chances are, when you swipe your credit card, that transaction touches a mainframe and probably some code that was written in the 1980s. Or earlier. I know, because I've seen the timestamps.
This compatibility is really evident when you use z/OS. The green screen is perhaps the most obvious example. When you see a systems programmer (that's mainframe-talk for sysadmin) debugging a system, you'll see them page through a really archaic, unsexy TN3270 interface. Why? The same reason Unix (and thereby Linux) uses teletype. Because that's what the operating system was built on.
Sure. z/OS has Unix System Services. In fact, it's even POSIX compliant. But can you `apt-get install ruby`?. No. There's no Ruby for z/OS (unless you count JRuby). There's no package manager for USS. It's just plain, vanilla Unix. There's no new open source contributions. There's no Bash that comes with the operating system. You get a 10 year old version of Shell. There's all kinds of shenanigans with SCP/SFP and ASCII/EBCDIC. IBM has to maintain the tools. (Actually, it's been turned over to Rocket Software.) It feels very "round peg, square hole".
So z/OS has an image problem. IBM made a huge mistake back in the mid-80s. When commodity x86 PCs became available, universities realized they could teach their computer science programs on cheaper hardware instead of expensive mainframes. Compute Science is platform agnostic, right? What IBM didn't do is recognize this as a problem. They didn't give out free mainframes to universities, so schools quit teaching with them. How many people do you know under 30 that had a mainframe-based curriculum? And for the self-taught, how are you suppose to learn the basics of a platform if costs millions of dollars? Anybody can install Linux on their $100 laptop in a few hours. But mainframes?
Fast-forward a couple of decades and now you have a talent pool that's extremely saturated with x86 people. And the mainframe people? Well, they are all retiring and there aren't many replacements. Second-generation mainframers are far and few. (I'm one of them.)
So let's say you have a new workload. It's undeveloped. What platform should you choose? There's probably not many technical reasons why you could not accomplish what you want to do in z/OS. But how many people do you know that consider themselves proficient with debugging z/OS? Outside of "dead languages", your options are pretty much limited to Java. (There's a few exceptions to this, but Java is the biggest modern language player.) But that's not to say there isn't any new development happening in the z/OS space. There's plenty of new workloads coming to WebSphere on z because porting a WebSphere application could be pretty easy. There's also performance benefits when you are on the same system where all your financial records are stored. z/OS is definitely an option, but it varies by use case.
With Linux on z, you get real Linux. And the majority know Linux. The majority can debug Linux. And you get the same benefits of being on rock-solid mainframe hardware and you get memory-speed I/O against mainframe data and services through a special networking interface called Hipersockets. Mainframes are also pretty good a virtualization, because they invented it. (z/VM has it's roots dating back to the 70s.)
That was definitely where they screwed up: universities. They have recent program pushing mainframes to universities more. However, they would've been better off (a) giving them to Universities at physical cost, (b) donating time to their students from a pool IBM themselves use, or (c) supporting the Hercules emulator for use in educational institutions that acquire licenses. This would've gotten more exposure. Each are still good moves today.
Not sure what they're actually doing but closing it off too much holds them back. It can still be proprietary. However, people need to be able to hack on it or a VM of it for best results. Preferably, a way for people to learn it in pieces so they don't have to know all mainframe stuff at once. Think the pre-configured, appliance VM's for various services. Have those for z/OS admins, CICS users, etc.
z/OS has a long history. It's predecessor, OS/390, dates back to the 1990s. Before OS/390, there was OS/360 which dates back to the 60s. Back then, IBM was first to market on business computer processing. (That was the only computer processing.) Major industries, like financial, insurance, and airlines, poured their infrastructure into mainframes, because it was the only name in the game. IBM prides itself in assuring its customers that the COBOL code that ran your business back in the 80s will still run today on z/OS 2.1 (the current version of z/OS). Chances are, when you swipe your credit card, that transaction touches a mainframe and probably some code that was written in the 1980s. Or earlier. I know, because I've seen the timestamps.
This compatibility is really evident when you use z/OS. The green screen is perhaps the most obvious example. When you see a systems programmer (that's mainframe-talk for sysadmin) debugging a system, you'll see them page through a really archaic, unsexy TN3270 interface. Why? The same reason Unix (and thereby Linux) uses teletype. Because that's what the operating system was built on.
Sure. z/OS has Unix System Services. In fact, it's even POSIX compliant. But can you `apt-get install ruby`?. No. There's no Ruby for z/OS (unless you count JRuby). There's no package manager for USS. It's just plain, vanilla Unix. There's no new open source contributions. There's no Bash that comes with the operating system. You get a 10 year old version of Shell. There's all kinds of shenanigans with SCP/SFP and ASCII/EBCDIC. IBM has to maintain the tools. (Actually, it's been turned over to Rocket Software.) It feels very "round peg, square hole".
So z/OS has an image problem. IBM made a huge mistake back in the mid-80s. When commodity x86 PCs became available, universities realized they could teach their computer science programs on cheaper hardware instead of expensive mainframes. Compute Science is platform agnostic, right? What IBM didn't do is recognize this as a problem. They didn't give out free mainframes to universities, so schools quit teaching with them. How many people do you know under 30 that had a mainframe-based curriculum? And for the self-taught, how are you suppose to learn the basics of a platform if costs millions of dollars? Anybody can install Linux on their $100 laptop in a few hours. But mainframes?
Fast-forward a couple of decades and now you have a talent pool that's extremely saturated with x86 people. And the mainframe people? Well, they are all retiring and there aren't many replacements. Second-generation mainframers are far and few. (I'm one of them.)
So let's say you have a new workload. It's undeveloped. What platform should you choose? There's probably not many technical reasons why you could not accomplish what you want to do in z/OS. But how many people do you know that consider themselves proficient with debugging z/OS? Outside of "dead languages", your options are pretty much limited to Java. (There's a few exceptions to this, but Java is the biggest modern language player.) But that's not to say there isn't any new development happening in the z/OS space. There's plenty of new workloads coming to WebSphere on z because porting a WebSphere application could be pretty easy. There's also performance benefits when you are on the same system where all your financial records are stored. z/OS is definitely an option, but it varies by use case.
With Linux on z, you get real Linux. And the majority know Linux. The majority can debug Linux. And you get the same benefits of being on rock-solid mainframe hardware and you get memory-speed I/O against mainframe data and services through a special networking interface called Hipersockets. Mainframes are also pretty good a virtualization, because they invented it. (z/VM has it's roots dating back to the 70s.)