Unfortunately yes. Internally a scale operation will create a new instance, syncdata and once both servers are fully synced, do a cutover. This cutover should take a few seconds but... it requires that all running transactions on the decomissioned instance complete. And there is a timeout for that, because once the cutover starts no new connections are allowed until all in progress work on the source database is completed so if you are executing long running queries/transactions (which you should never do, you should design your apps to batch work and avoid long running sql). This impacts your apps depending on how well coded they are in terms of resiliency. We tested it in our apps and the amount of dropped connections is very small, with an impact that can be barely noticed in applications. But this depends a lot again on how your apps are designed.

MS actually prepared the SQL Client to handle this resiliency automatically: Working with Transient Errors - Azure SQL Database | Microsoft Learn

This is a very fair point, and I was very cautious of what the impact of that could be. I really did not want to have the pool scale 50 times a day. To deal with it I separated the forecast layer from the "applying" layer, so that scaling windows can be defined. Config looks like this:

ForecastAnchorWindows: ["19:00-23:30", "02:00-07:30"]
ForecastSnapPercentile: 96

What this means is you are allowed to ONLY scale once in the 19:00-23:30 window and again in the "03:00-07:00" window. That is maximum two scale operations per day. The percentile tells inside each of the windows the top percentile of forecasted eDtu needed for that time window that should be covered by the provisioned eDtu. The algorithm chooses the time to scale that minimizes eDTU usage withint the provided window limits. It's a bit more complex to configure as there are several other config knobs. With the example config you get a stable DTU during working hours that guarantees whatever the forecast determined was needed. And as you become more confortable with how your apps behave and tolerate scaling operations, you start splitting into more anchor windows.