I think AppleScript's problems have more to do with the fact that it relies too much on external parties to do its stuff. The moment you do

  tell application "foo"
    every bar whose third baz is frob
  end tell

whatever you write in that tell phrase gets executed by application "foo" (the logic runs in the process, and has to be written by the implementers writing the "foo" application). Implementing that flexibility is lots of work and hard because Apple did not supply much support libraries (1). Because of that, all implementations were incomplete (and differently so) and buggy. That "and differently so" was the main reason one cannot get comfortable writing AppleScript. Even if the above worked, there was no guarantee that, for example

  tell application "foo"
    the third baz of every bar
  end tell

worked.

The essence of AppleScript goes very far:

- The editor imports syntax from "foo" the moment it sees that tell application "foo" block.

- When compiled, it converts that into a standardised binary format (an Apple Event)

- When run, AppleScript sends that event to "foo", and "foo" parses and executes it.

In essence, it turns application "foo" into a service that shows its internal state in its GUI (in 1993).

(1) in their defence, I don't think they could have written good support libraries in the language of the day. A few C++ 'interfaces' in header files might have helped, though.

Yes, implementing the object-oriented Apple Event Object Model (the conceptual model used to refer to properties and elements in another application) can be challenging to implement in a non-OO language like C. These days, Cocoa Scripting (in the Foundation framework) provides most of the code to map from Apple Events to Objective-C method calls, and using a language like Objective-C makes writing the rest of the code much more straightforward.