From a network engineering standpoint, for technical reasons the SmartThings hub is definitely a hub and not just a bridge. (You will find discussions elsewhere in the forum about the difference between a hub and a bridge in this context.)
However, from a customer point of view it is a black box hub because customers are not allowed to load any code onto the hub. At all.
( this is where many people who have a technical background get confused, because they think they are buying a customer – accessible CPU with server capabilities. Sort of like a preloaded raspberry pi with a home automation stack. But they're not. They're buying a black box hub which is part of a cloud-based architecture.)
Smartthings itself is not the hub. It is a cloud-based platform. Customers are allowed to load code into their cloud account. This can be code that they wrote themselves or that they copied from other community members or that is available to load from the "published" library that you can see in the marketplace section of the SmartThings mobile app.
Once the code is loaded into the customers cloud account, it runs in the cloud, and some of the output of what runs may be sent to the hub device at the customer's home. But it's entirely possible to run a smartapp which never send output to the hub at all.
Meanwhile, the hub and the cloud talk to each other regularly and exchange information, independent of anything that any smart app is doing. Colloquially, we would call this housekeeping. It's what keeps the status of devices in sync, let's the cloud know if the hub is off-line, and some other stuff. But none of that is accessible to customers, it just happens as long as the hub is signed into the cloud account.
The SmartLighting Exeception: Local Execution
SmartLighting is an official feature which is unusual in that it specifically has been loaded into the firmware of every hub device and consequently can "run locally." However, the hub is still a black box device. The customer cannot access it locally or make changes to smartlighting locally.
Instead, the customer makes changes to smartlighting in the usual way, in the cloud, and then that gets sent by the cloud to the hub for local storage. If the cloud is not available, for example, there is no way to change an existing smart lighting automation. It will just keep running with the old parameters.
So "run locally" in this case literally means "execute locally," there's still a required cloud component to set up a rule in the first place or make changes to it.
There some discussion of the SmartThings architecture in the developer docs and it's worth taking a look at. But the Main thing to remember is that code that you write is going to run in the cloud. It's the outputs that may get sent to the hub to act on if local device control is needed.