Is there a time-out period for SQL to disconnect if no activity ? that would be an issue.
Execute sp_configure without any options to see what is configured, not only regarding timeouts.
There's actually only a timeout literally named connection timeout that determines within what time the connection has to be established, exceeding that the connection fails, that timeout is overlooked by the ODBC driver, as the most likely timeout is when the server is even too busy to react to a connection. There's also a query timeout within which (a) query result(s) should be established and if not, gives an execution timeout error, by default 10 minutes, that doesn't close the connection but still will need to be handled.
Once you have a connection, reasons for server side disconnects still exist, though, not only by admins closing connections manually, obviously also when restarting the server. A deadlock, I think, cannot only choose a winner getting a result and a looser getting an error, I think it can also cause a disconnection. A crashing application, when it crashes "gracefully", so that at least the process that ends by a crash closes all file handles and connections, too. But that's obviously a case where that's not the main problem and good to have to not have dangling connections etc.
It's also a reason to have a mechanism of reestablishing a connections even in desktop applications that usually keep the initial connection open for the whole application session. Anyway, you will get informed at least by triggering an error in the next SQLExec, use of a cursor adapter or remote view, etc. that the connection you try to use is closed or in case of query execution timeout the result is an error instead of a result.
With a connection established at the start of each request you will much more unlikely encounter such problems anyway, but the point is that too many open and never closed connections could lead to denying any further connections. And you should actually set it to a sensible value, because your server can go into very unresponsive state, whereas it doesn't crash by that, which can be even less pleasant than a simple downtime you solve restarting, if your server isn't dimensiond for 32000 concurrent users, then also don't allow as many. Even when an idle connection is not a direct load to the server performance.
Any open has a close, any declare a release, etc. etc., so of course, and especially since you know you establish a connection for each new request, you also close it. Or we get back to the quest of how to not need to do that repeatedly. I'd say it has more pros than cons for web development. The reason is the same as the architectural choice to have a stateless server: It can handle each request independently of previous request (except for things like user session handling, which I already pointed out how they are stateful though they are stateless) and to be able to route requests, if the demand requires it and to do load balancing.
The browser, that's usually the frontend for a user, also is merely a viewer of HTML than it is a desktop application in the classic sense of it, therefore we talk about web applications, don't we, and make a distinction. A browser is not only handling a single website, too, but a general purpose web application viewer, it compares much more to a desktop of web applicaitons as to the main window of a desktop application, isn't it? So you also have to think of it as that and not act as if you're alone, neither on the server nor in the browser.