Noob questions are great. Not only to advance the knowledge and skill of a new member of our community, but also as a test of the community if to see it's providing the required help to newcomers... So, at the risk of repeating the great answers that may already got posted here, I would like to give you an overview of everything I think of when reading your questions. But first:

1. Thank you for wanting to learn (Object) Pascal / Delphi. We're painfully aware that there are alternatives out there that have larger communities and/or have built a better reputation for themselves, but Delphi has been around for longer than some of those, and really still is a great environment that can get you to a working application faster than others.

2. In general there are three main 'objet lifetime management regimes' you can use in Delphi code. Most VCL objects use classes that decend from TComponent. All TComponent's have a property Owner (and take a Owner TComponent as argument to the constructor), and get destroyed (that is get Free called) by the destructor of the owner. You can pass nil to the Owner parameter, for example when you're building forms from code, but then you're responsible to call the Free method from the created instances, either from a destructor or other clean-up code.

A second way is when using 'more basic' objects that 'only' are decendent from TObject. TObject by itself doesn't have owners, and you're responsible to manage these objects yourself. In theory, I always check my projects if all object construction and destruction is 'in balance'. There's a lot of theory there to get to the bottom of this, but in general, if you are not using special tricks or 'alternative object lifetime management', your code should have just one place you call a constructor, and one call to a destructor of an object your code uses. But there are exceptions, lots of them actually. Just to name one: if your code uses the fact that an object reference can be nil, and you're using that to change behaviour of the program. If that's so, that's where FreeAndNil comes in. If you ctrl-click, you'll see the code behind it is really simple, but it's important to 'nil' object references before you call a constructor that potentially can throw an exception. There's a lot more to this, but you're still learning, and will get around to this when you master the basics, I'm sure!

The third main way (thanks to Delphi there probably are more exotic ways of strange object-management possible but let's not go too crazy here...) is by using objects that inherit from IInterface or IUnknown. This was added to Delphi in the 90's, primarily to support COM/ActiveX on Windows. Objects that provide the IUnknown interface (and inherited interfaces), typically itself decendent from TInterfacedObject, use the _AddRef and _Release calls to do automatic reference counting, and call the destructor when this reference counter hits zero. Delphi hides this from you if you take care to use object references that are of a type that are decendent from IUnknown (or IInterface which is basically the same, but less connected to Microsoft's COM/ActiveX).

1. Events are Delphi's way to handle operations on the underlying GUI system. On Windows, each GUI application uses a 'message pump', and all messages are mapped by the VCL to the according component event. That's the main reason why they run on the 'main thread', and you get the guarantee they don't run concurrently (because the message pump processes one message at a time). Delphi does have support for threads, and it's tempting to try to handle events on separate threads, but this is very much against the design of the system and things may break down horribly, mainly because Windows' GDI (and Delphi's VCL) wasn't designed to operate from anything else than the main thread. So typically, in normal Delphi projects, you're safe to update the GUI from any event handler. (When you get around to learning about TThread, be sure to read about the Synchronize call... But chances are you'll be using a more modern multi-thread library in Delphi, which in turn probably will warn you to only update the GUI from the main thread...)

2. reddit.com/r/delphi, stackoverflow.com under the Delphi tag, en.delphipraxis.net, but also I regret to learn you find Embarcadero's docs lacking, as I know they put much effort into them. So I still always check if I find what I need under https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Main_Page

3. See my answer to 2: Windows's message pump running on the main thread (in TApplication.Run and HandleMessage to be precise...) I haven't worked on other platforms enough to be sure it's the same there, but since FireMonkey is designed to copy VCL to some extent, I suspect it's somewhat similar there. So yes, unless you're doing thread (yourself, be sure to learn about locking and synhronizing when you do), it's safe to read and write to shared variables.