I do not have an Apple Silicon Mac but I have worked with the ODBC driver on various Unix platforms and these sort of problems are typically because of where the libirisodbcur6435.so driver looks to get its configuration files vs. where the driver manager (in this case, unixODBC) looks for its configuration.  Also, how have you installed the libirisodbcur6435.so driver?  Is it part of a "stand-alone" ODBC kit or part of a server installation? 

You can determine where unixODBC tries to find its configuration files by running:

odbcinst -j

which on my Intel Mac system returns:

unixODBC 2.3.7
DRIVERS............: /opt/local/etc/odbcinst.ini
SYSTEM DATA SOURCES: /opt/local/etc/odbc.ini
FILE DATA SOURCES..: /opt/local/etc/ODBCDataSources
USER DATA SOURCES..: /Users/mburstin/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8

Meaning that it looks to find its DSN configuration in /opt/local/etc/odbc.ini.  I have found that the odbc driver sometimes wants to get its configuration information from a different location.  You typically can either create a symbolic link to that file (I will explain below how to find that) or by setting the ODBCINI environment variable to point to the odbc.ini file that the driver manager us using it which will force libirisodbcur6435.so to use that file.

To determine where libirisodbcur6435.so driver is searching, you can use the following in one macOS terminal:

 sudo fs_usage isql | grep ini

while running your isql command from above which will generate output looking like this:

11:02:10  stat64            /usr/lib/system/libsystem_secinit.dylib                                          0.000002   isql
11:02:10  open              /opt/local/etc/odbcinst.ini                                                      0.000029   isql
11:02:10  open              /Users/mburstin/.odbcinst.ini                                                    0.000007   isql
11:02:10  open              /opt/local/etc/odbcinst.ini                                                      0.000021   isql
11:02:10  open              /Users/mburstin/.odbcinst.ini                                                    0.000005   isql
11:02:10  open              /opt/local/etc/odbcinst.ini                                                      0.000019   isql
11:02:10  open              /Users/mburstin/.odbcinst.ini                                                    0.000004   isql
11:02:10  open              /opt/local/etc/odbcinst.ini                                                      0.000019   isql
11:02:10  open              /Users/mburstin/.odbcinst.ini                                                    0.000005   isql
11:02:10  open              /Applications/ISC/mikebsql/mgr/irisodbc.ini                                      0.000063   isql
11:02:10  open              /Applications/ISC/mikebsql/mgr/irisodbc.ini                                      0.000032   isql

Meaning that my driver (installed in /Applications/ISC/mikebsql) is looking for a file /Applications/ISC/mikebsql/mgr/irisodbc.ini

Take a look at Sample.ResultSets in the samples namespace.  There are examples in both PersonSets and CustomSets methods.

According to the %SQLGatewayConnection documentation, you should be able to pass in an empty string for username and password to have the code use SQLDriverConnect() which would do what you want it to do, however, I did some testing and see that it isn't working properly.  I put in prodlog 142095 for this problem.  Do note that when this is fixed, you will need to use an empty string for user and password and not simply leave them off of the call to Connect(). 

The code that I was using testing against Cache was:

s cs = "Driver=Intersystems ODBC35; Server=localhost; Database=samples; Port=1972; UID=_system; PWD=SYS"
s gc = ##class(%SQLGatewayConnection).%New()
s st = gc.Connect(cs, "", "")

I cannot say what the proper connection string would be to connect to MySQL - you would need to consult the MySQL ODBC driver documentation for that.