Hypercard had a really nice programming language with automatic formatting and (eventually) an excellent debugger. The code was both easy to read AND write, and it was pretty easy for a competent programmer to understand clean up dodgy code written by a novice.

The view hierarchy was very simple: card controls, card, background controls, background. And the event hierarchy matched it and added a couple of higher levels.

All variables were strings. (This turned out to be a significant problem when it came to adding features.)

At a time when string manipulation tools in most languages was quite hard, it was insanely easy in HyperCard (e.g. the concept of "split" was intrinsic to the "chunk" system for string manipulation).

The environment itself was incredibly stable, and by default all your work was persistent and everything you did was persistent (making things volatile was extra work). E.g. if you changed the name of a button with code, the name change stayed. By the same token data and code lived together in this persistent world.

It was all based on direct manipulation. Want to create a button? Draw a button. Want to change its script? Command-option click on it OR go into edit mode and double-click on it.

The drawbacks of HyperCard were more interesting, especially since efforts to produce third party replacements usually managed to address "obvious" shortcomings, while losing key bits of magic (e.g. stability).

Years after moving away from HyperCard I did a bit of Toolbook development -- of all the HyperCard clones I tried, it was probably the best (and certainly addressed a lot of HyperCard's shortcomings).

The "card" metaphor added an artificial constraint to programming that helped a lot of people figure out what they wanted to do and get it done quickly.

You weren't handed a command line and told "okay, now make a program out of this and, oh yeah, you'll need a UI". The UI stuff was pretty much baked into the system. Cards were your screens, and elements could be quickly dropped into place.

Things done to cards stayed put when you traveled back and forth through the stack. That's an important nuance. Also, most of the UI elements were already set up to do some simple things and make the stack work, but later they could be scripted into doing more advanced stuff.

WIMP UIs were still a really really new thing in 1986, but HyperCard was the first construction kit that let you play with that system without learning all the underlying toolkit code.

It may have had something to do with what was available at the time... For myself I had an old Mac plus and it had basic and HyperCard. Creating graphical games was HARD in basic. In HyperCard I could just draw a picture in it, make areas clickable add some script and voila! I made little cheesy Myst-like games.

As it progressed they made it easier to play music on queue and play video. Eventually I moved onto the web but the web was also complicated by JavaScript which I avoided for years.