I dont think that static sites are less well suited for dynamic content than other server architectures. There is complexity in working with either pattern, neither method is inherently better at the surface.
I dont think this question has as much to do with hugo as it does with the general ideal of how the client side connects to the various api’s that it needs to populate the various types of data you have throughout your site(s), and there is no inherent relationship between a server side framework and how a client side application accesses various API’s to populate data. In modern web applications all the dynamic magic, all the key security stuff, it all happens on the client side, and, as it relates to your use case, the server side simply feeds javascript, html and css to the client side but all the processing still happens on the client side. In more traditional server-side frameworks, the client side may still build a page where the client goes directly to a google maps api or through a central chokepoint, likewise a server side framework does not force or even typically rely on web-app-user authentication to be handled through the server-side. Where traditional server side frameworks are more substantial is if you are a big company and you are writing a bunch of distributed microservices and you had to think about things like distributing api server configuration and secure keychain data during server-side dynamic scaling events for distributed microservices applications.
Fortunately for those of us that arent doing things that are anywhere close to needing massive scale custom complex apps like that, even for the most giant they use web services available over from public web services and saas companies as much as possible, and whether a client side page directly accesses various API’s to get data to build the page or goes through a central server-side api gateway is simply a matter of how the javascript on the client side is configured, and hugo can serve that javascript just as well as anything else imho.
The most important point here is having a server side framework does not at all change the need to build a client side application. You can write your client side application in a different language that will dynamically build the client side app in html/css/jss or you can work with any number of different ways to get the html/css/js and then serve it in any number of ways, you may find that certain features that other server frameworks may be more compelling to you, but personally I think you will be better off focusing on getting the client side app the way you want it first and then going from there.
For your use case the problem isnt so much that static-site generators cant do what you need as much as there arent as many of these types of templates for hugo but you may end up serving the web app you build in another framework with hugo, the central questions are how you can create and manage secure sessions in a client side web application, and how you provide authentication services and other services which in any case until you are massive scale will make most sense to get as a service and not try to build your own microservices.
For your use case, I would suspect that a Single Page Application (SPA) pattern may be ideal … dont let the name fool you, its not really meant for a single page, I think of the pattern more like a single web application, like for example your website. And the SPA pattern can support your website getting really big like to the point if you had to worry about it again you would have your own team of web devs. The benefit of the SPA is, it maintains availability of all your client object model, script objects and your security posture across all of your various pages, because as you know javascript can make entire pages or directory structures appear and disappear, like for example a page that has multiple tabs may actually be a single page where javascript exposes the text when you click on the different tabs but its actually all one page. So the SPA pattern is actually using javascript to embed an entire web application in the context of an entire page which makes it much easier to do things that involve using scripts to provide user interaction features, produce dynamic content, or just maintain security continuity as the user browses through your content. You could also use a SPA for only a portion of your website, or have some pages serve html that was generated by a SPA framework by hugo and hugo serve other standard static and md generated content, but then you would have to worry about how you would pass objects and security context between different areas of your site and maintaining continuity of appearance between the frameworks and pages. If you can meet all your needs in the context of a SPA and I strongly suspect you can, it will greatly simplify your life and you shoudnt have to think about growing beyond the framwork until your massive enough to have a dedicated web team 
And once you create your SPA, you can still choose to serve it with hugo on github pages, its just html/css/js.
