My route table is configured to forward traffic to this IP address through my Virtual Private Gateway.
I don't think there is a possibility of this specific approach working, because...
I have the route table of my gateway subnet configured to forward traffic destined for the Microsoft.Sql regional endpoint public IP address to my proxy VM as if it were a virtual appliance.
This route table applies to traffic originating in that subnet, and that isn't where the traffic originates.
You need to tunnel this traffic between the two machines, not just route it, because the source and destination addresses that the network sees need to be the addresses of the individual VMs. That's part of what a tunnel does -- speaking generically and over-simplified, a tunnel wraps traffic from/to hosts with addresses a and b inside outer packets with from/to hosts with addresses x and y so that intermediate networks and gateways need not understand the "real" source and destination. Platform limitations probably make it impossible to simply route and forward this traffic as unencapsulated IP traffic with source and destination intact. (Or, without a proper tunnel, you'd need to NAT or double-NAT the traffic on the instances on both ends.)
There are a number of tunnel solutions operating at different layers, including openvpn and HAProxy, but the simplest -- for proof-of-concept purposes, at least -- is an SSH tunnel.
From the EC2 instance, assuming the database is using TCP port 1433:
$ ssh -L 1433:private-ip-of-db:1433 -i keyfile.pem username@ip-of-azure-vm
With this SSH connection open, there is also a socket listening to TCP port 1434 on the EC2 instance, and any connection to the private IP of the EC2 instance on that port will be tunneled across the open SSH connection and relayed to the database. The database will see the source IP of the connection as being the IP of the azure VM... so security settings need to allow traffic accordingly, and you wouldn't use the public IP address you discussed -- you'd use the EC2 instance's IP and control access via the EC2 security group, and you'd need to give the Azure VM access to the database. From the perspective of anything accessing the database, the EC2 instance appears to be the SQL Server.
SQL Server may offer one or more gotchas that requires more ports or a different port than I've shown above, but the general idea here is solid -- I've used this strategy for other protocols like RDP (TCP port 3389) and MySQL (TCP port 3306) but don't recall ever trying it with MSSQL.
Best Answer
From the error code you have provided (10060) I'd guess that's a firewalling issue:
I have found this within the Azure Data Factory documentation
So it seems you need to open and properly configure your SQL MI's public endpoint. More information on this can be found here: Configure public endpoint in Azure SQL Managed Instance.
If your are willing/able to migrate your database from SQL MI to a SQL DB you can also make use of a managed private endpoint. It would establishe a private link to your database and keep your data on Microsoft's backbone. Unfortunately
Azure SQL Managed Instances
are currently not supported.