No worries, Shane, I didn’t perceive your feedback as criticism of the entire course. And even if you meant the entire course: We are glad that you let us know that you were struggling. Our instructors are always interested in constructive feedback which allows them to improve their teaching skills. 
And I’m just struggling with trying to figure out how things within unity itself can interact via scripts.
So, you’re struggling with the most important topic. 
I had the same problem when I started with Unity. It’s not like that I hadn’t had any affinity with logic. That’s why I stopped learning Unity and C# simultaneously, and focussed on C# first. Once I understood how C# (and OOP in general) work, I was able to regard the Unity editor and the C# part as two different things.
To put it simply: The Unity Editor is fairly simple, and so is the core project. They cannot do anything unless you create a script and attach it to a game object in the Hierarchy. And that’s it.
The actual logic is wired up in the C# scripts. You define there what is supposed to happen to an object, e.g. “move this object”. If your Player has got Health, you reference the Health object in the Player object. Just like you would do it in a normal C# script. The only difference is that you usually do not use a constructor when working with GameObject objects. A constructor is a special method in C# creating a new object.
Vector3 position = new Vector3(1f, 2f, 3f); // that's what you often see
Player player = new Player(); // that's what you rarely see
Instead of calling the constructor, we assign the reference to the object to a field manually in the Inspector. Our code just looks like this:
[SerializeField] Health health;
And that’s basically everything there is to know as a beginner.
Don’t get confused by the pretty pictures we are using in the scene. They are just pictures. The actual logic is in the code. In the code, we define how objects are supposed to interact with one another.
When you assign the Button component, you are assigning an object. The Button class is a script just like yours. So are SpriteRenderer, Image, TextMeshProUGUI, and whatever you attach to the Inspector of Unity.
Unity just visualises stuff.
Unless you are struggling with Unity’s GUI, it is usually fine to ignore Unity and focus on the code itself when you are lost. A good programmer aims for self-explanatory code. That’s not always possible but at least one should try.
For this reason, if you feel lost, ignore what you think you understood and just take a look at Gary’s classnames: GameManager, QuestionSO, Quiz, ScoreKeeper, Timer, Endscreen. Read them as if you were a random person on the internet. Do you have a rough idea of what might be going on in the game project just by reading the classnames?
If the answer is yes, you could take a look at the content of the classes. Depending on how complex the logic is, it could make sense to visualise it in a diagram. Code is not some cryptical poem, there is a strict logic behind it because the computer cannot interpret anything. It just executes the instructions in the code, and that’s it. Of course, the instructions could be “wrong” regarding the programmer’s initial idea but that’s another story.
Furthermore, in many cases, there are multiple ways to realise this game, so regard Gary’s solution as one way to solve the problems not like “If I don’t understand every single detail and learn the code by heart, I’ll never become a game developer”.
I’m actually in college for video game programming and grabbed these courses as a helpful addition to that program so I’m trying to make it all make sense at once.
You are not saving time by trying to learn everything at once. The good thing is that most softwares in this field and most programming languages use the same or similar concepts. If you know Unity, you’ll learn other game engines faster. And if you know C#, you’ll learn other programming languages faster.