It is not necessary to include loop design into the GDD, especially if you don't understand. Loops are coding, not design. From your GDD a good tech lead can come up with loop structures.  A loop design in a GDD can be represented by a state diagram or a flow diagram. Any overall game loop will inevitably involve smaller sub-loops (while the player is fighting a boss, a combat loop is in effect, for instance). But if you aren't comfortable with wrapping your head around state diagrams and loops, then you don't have to design them. As I said, the coders will create the loops in the normal course of their work anyway. 

I think, in this case they may be referring to a different type of loop, as described by Daniel Cook in this Lost Garden post.  In this usage of the term, it would be part of the game design.  Ambiguous wording on the part of whoever designed your template - is there any additional prompting or examples along with the template that might clarify whether my guess is correct?

Otherwise, I would agree with Tom, a game loop in the traditional programming sense is not something that would typically need to be detailed in a design document (but might appear in a Technical Design Document if you have specific requirements).  The other type of loop described in the link is a newer use of the term, that isn't necessarily understood everywhere without clarification.

Documenting a "game loop" involves strictly technical aspects like buffering and multithreading schemes, but also very game specific design decisions like the sequence of rendering and simulation steps, which are potentially important game design details.

For example:

• In a realtime action game, if type A moving actors (e.g. guided missiles) chase type B moving actors (e.g. vehicles of some kind) do you give the respective AI (which decides the next turn's movement and steers the actor) the old or new position (before or after this turn's movement) of the enemy actors? Knowing the new positions is a significant advantage, which can drastically affect game balance.
• How long do you need "dead" entities after the specific simulation step (e.g. bullets vs combatants collision detection) in which you figure out they die? For example a part of their accompanying data might be required to compute score, and score can only bi computed after                                                                        

9 hours ago, jbadams said:

may be referring to a different type of loop

Yeah, I forgot about those. 

Often there's two loops to a user's experience. To use a collectable card combat game as an example:

* the mechanics loop involves choosing a card to play, waiting for the right time to play a card, and reacting/watching what cards the opponent has played. 

* the meta game loop then might involve entering into battles with opponents (entering the above loop), gaining rewards from those battles, unlocking new cards using rewarded currency, curating your decks of cards, etc. 

6 hours ago, JoAndRoPo said:

a Core loop & a Compulsion loop is the designer's job, right?

It is certainly nobody else's "job" to come up with these. The designer's job is to design a fun experience for players. These loops can be derived from the overall design - they can be a tool to clearly communicate the design vision to teammates. But these loops can also be used by the designer to identify areas in the gameplay where improvement is needed. 

6 hours ago, JoAndRoPo said:

Is it important to add a core loop in the game design document as shown in the attached image?

It's not strictly necessary, as discussed in previous responses above. These loops are a way of visualizing the player experience, and as such can be useful to explain and help readers visualize the gameplay. Anything you can put into your GDD to help your teammates understand and develop your vision is good.