This is an industry-wide problem, and managers in general prefer products from "blue chip companies" like Microsoft or IBM over products from small players. There's a high probability that the big guys like Microsoft will still be around tomorrow, but there's no guarantee that the mom & pop garage shop will still be in business next week.
Also, it's easier to find other developers in the market that know how to work with the big company products, but with niche products, it always becomes difficult and thus by definition more expensive and riskier. Look at it from a managerial perspective, it's much smarter to develop Android products in Java or Kotlin, iOS products in Swift and Microsoft Windows products in C# -- these are the platform native tools and developers for these tools are a dime a dozen. When you plan a software product, you don't expect the original developers to still be there five or ten years from now - but you usually expect your product to still be there. Who's gonna maintain it then? The one guy who had the fancy idea of using a completely unknown tool and who probably will have moved on to the next completely unknown tool just because that's even fancier? Or will it be a bunch of young students who have already had their first contact with industry standard tools in school or college?
You mentioned that person is a retired COBOL programmer - I rest my case: These guys are very rare these days but still in high demand and very expensive. And they can still use tools that were designed 50 years ago, because COBOL was - and in mainframe environments still is - an industry standard. Yes, that's right, banks and insurance companies still write new COBOL code every day. Just because COBOL never made it to the PC doesn't mean it became irrelevant.
This is not a discussion you can successfully have with the guy or anybody else in his position. But it's a discussion that you will always be having with yourself when you entertain the idea of working --with-- or --for-- other people. You are using a niche tool, the others out there don't. So it will always be you who doesn't fit in. (Been there a million times myself, it never stopped to suck.)
The question you need to ask is whether you ever want to fit in and do what everybody else is doing. If that answer is yes, then dump B4X and pick up Kotlin and Swift for mobile development, improve your C++ for the desktop side of things and if it's the (web) server you're after, invest in Go and Python -- and avoid the legacy languages Java, Perl and PHP, unless you want to maintain horrible old code bases others have written twenty years ago. Legacy and corporate stuff isn't interesting, and you can rest assured that interesting new stuff (emphasis on interesting) isn't written in Java or PHP or Perl anymore, full stop.
If you want to stay independent and do your own thing, then stick with the tool that you know and like the best and don't ever think about going down the corporate road again - event though corporate positions come with safe salaries, they do not include any space for creativity and playing the corporate game will only kill your brain and make you unhappy.
I could now write a lot about why all system engineers and system administrators worth their money hate the Java platform with a passion, but I'll leave it. Let's just say that in reality, outside of all the marketing nonsense and a developer's wishful thinking, the Java platform is only multi-platform on paper and experience dictates to avoid everything that requires the resource hog and maintenance nightmare called Java Runtime Environment whenever possible. (Even more so now that admins either have to mass deploy an open source/third party JRE or pay license fees to Oracle for deploying the official JRE - this is a huge and costly problem for enterprise-size deployments. The JDK can still be rolled out as is, but that is not what you do on a typical company/enterprise desktop, and Oracle knows that...)
