Any server fronting access to a database can be abused and to say one is better/worse than the other with regards security is a specious argument to say the least. For example, Dmitry has been able to easily get third-party access to the IRIS server by using an easily observable, though unpublished, protocol offered by InterSystems own server. Presumably, a malicious developer would be able to do the same. Of course, the same would be true of our server.
As Rob has mentioned, the reason why we don't use the InterSystems superserver is that the protocol is unpublished and, as far as I know, permission for third party products to use it has not been granted. That, in itself, would be enough to ring alarm bells with the customers that we deal with. Also, InterSystems have the right to change their protocol, or restrict access to it downstream - and without notice.
There are 2 connectivity modes to choose from for mg-dbx-napi.
1. API based - in which case you don't need any superserver at all. So, this mode will work "out of the box".
2. TCP based - you do, of course, need a superserver for this. We cannot use the InterSystems superserver listening on port 1972 as that's a proprietary server provided by InterSystems and, as far as I know, there's no public API for third party products to use. If there was, we would use it. But, for now you have to use our superserver - which is not a big deal for most of our users.
Our mg_go interface (in common with all our other language bindings) can invoke M functions and Cache/IRIS class methods - the latter being only available for InterSystems platforms of course. SQL statements can be embedded in those functions/methods. So mg_go can work with SQL, albeit indirectly through functions/class methods. Those wanting a purist SQL interface would probably be more comfortable with a JDBC/ODBC solution.