Having used Svelte on a large project, I found that it did scale reasonably well but that the usual problems did require effort and trade-offs. The two big ones for me were:
- Managing file size and complexity in the component-per-file paradigm. Having all logic for a complex component in one file makes it big, e.g. 1,000 lines, but splitting into multiple files introduces a component boundary and consequent state passing/event handling boilerplate.
- With tight coupling between a complex UI and complex domain objects/data structures, it becomes difficult to reason about data flow. There are multiple ways of binding the data to the UI -- props, stores, standard JS variables, and reactive statements -- but all come with trade-offs and none let you develop domain objects that are completely framework-agnostic without introducing repetitive boilerplate.
For certain types of app I actually really like the DX of writing a UI-agnostic app and then layering Svelte on top of it with event handlers. It's repetitive -- you have to manually listen to events from the domain objects and update local variables with assignments -- but it's easy to reason about and seems to scale well. A good middle-ground might be making the app aware of the Svelte store contract, which is also very simple, but I haven't tried this and the store syntax comes with its own idiosyncrasies (you can't do $obj.store, for example, because only the $obj bit is interpreted as a reference to a store).