^if(query)^…^endIf^ is the export code equivalent if the action code if(query){…}. Same role in both cases. If the query evaluates as true, the delimited code is executed. If If the query evaluates as false, no code is execute. Both export and action code offer an ‘else’ branch.
The generic logic is:
if(query) code to run if query is true / else / code to run if query is false
Added how? Unfortunately the question is too loosely stated to answer clearly. Note that $text refers to the user attribute whilst $Text refers to main body text of a note Attribute names are case sensitive. Indeed, whilst you can use use case you like for attributes (price, Price, PRICE, etc.) it’s a good idea to follow Tinderbox norms especially if you want others to understand your code. At the same time, others value using naming styles more familiar from other apps they use. All said, it’s a personal choice. System attributes must be used in the case defined by the app (not the user)
Yes. Read up on references and designators, especial the ‘parent’ designator.
Some had the wrong prototypes, this ended up with the wrong font style (e.g. you couldn’t see where the insertion cursor was). Your template handling the descendant notes “JSON GlossaryItems” was trying to call ^descendants()^ ( list of descendants) rather than use the envelope-letter mechanism to which I linked in a previous post. As a result it wasn’t working as you envisaged.
Fear not, you aren’t doing anything wrong per se, but having bad luck with your guesses. Pretty much all the questions above are covered in Help, the app’s Help menu tutorials, or aTbRef. Part of the secret is not trying to do too many things at once. For instance, I’d start with things like how to fetch an attribute value from a different note. Then when you need to use that technique in the template it is no longer a mystery.
Although not strictly the case, it’s a good starting assumption to assume all app-defined codes (Attribute’s names, action code operators, export code, designators, etc.) are case-sensitive. That way you won’t inadvertently colour outside the lines—at least not before you chose to doing so because you know where it is safe to do so. 
for someone actually, at last, using Export pane rather than Preview (doc opens in text/Export pane) to check export. Seriously, doesn’t happen enough. Preview shows that export worked/failed, but Export tells you why.