HyperCard's real strength was that it allowed mere users (not programmers) to create their own apps (or "stacks", in the HyperCard parlance) through pointing and clicking, plus an English-like scripting language (HyperTalk).
We have largely abandoned the idea that users should be able to create their own apps, so there is no popular, modern analogue to HyperCard, though some people keep trying. For instance, LiveCode is a commercial product that is directly inspired by HyperCard. And CardStock is an open source HyperCard clone that swaps out something English-like for Python as the underlying scripting language.
When Hypercard launched, it came with every Mac, it was free, and there was nothing else like it available on the Mac. On the Mac, the alternative to Hypercard was to layout UI widgets in code, with no GUI builder at all, or eventually to pay $$$ for a professional-grade IDE like CodeWarrior. As an entry-level user with no budget, if you wanted a GUI builder for the Mac, you got Hypercard, or nothing. This created a community of Hypercard enthusiasts.
Furthermore, when Hypercard launched, Macs had a standard screen resolution. Every Mac sold had a screen resolution of 512x342 pixels, so you could know for sure how your cards would look on any Mac. Supporting resizable GUIs is one of the hardest things to do in any GUI builder. (How should the buttons layout when the screen gets very small, like a phone? Or very wide, like a 16:9 monitor?) Today, Xcode uses a sophisticated constraint solver / theorem prover to allow developers to build resizable UIs in a GUI; it works pretty well, I think, but it's never going to be as easy to learn as "drag the button onto the screen and it's going to look exactly like that everywhere."
The last issue is the real killer for modern Hypercard wannabes: it's a small step from a web GUI builder to raw HTML/CSS. You don't have to pay big bucks to have access to professional-grade HTML, CSS, and JavaScript. Sure, they're not that easy to learn, but you can teach a kid to write interactive web pages, no problem.
As a result, the demand for a simple GUI builder is lower than it was for Hypercard, and even when you do capture a user, they tend to outgrow your product, and there are a zillion competitors, so none of them can build a community with real traction.
Even if you stick to only HTML, it's not nearly as fun to make.
It even looks a bit like Hypercard, by default (it's lo-fi, but there are colors under the hood).
HyperCard came about in an era where personal computer users were still being inculcated into what using a computer even meant. That was the moment to let end-user programming and malleable systems like HyperCard take over. (A somewhat similar thing might be said of OpenDoc, but that's a bit different)
From a corporate perspective, what even was HyperCard? A way computer users could just make their own basic applications? How do you continuously make money? What about your computer's dev community? Because of these and other commercial concerns, both the way users today engage with personal computing _and_ the tools we have to manipulate our computing environments are strongly determined by a consumption model -- and there exists a strong bifurcation between users and programmers.
We have no true HyperCard equivalent today because personal computing went in a different direction.