For proof automation in Coq, when is it appropriate to use canonical structures or Equations instead of Ltac?
Choosing how to structure your development based on what proof automation you're using seems backwards.  First you decide what functions and definitions you want to prove theorems about, then you decide what theorems you want to prove, and then finally you decide how to prove them.  Unless you are doing interesting abstract math, it is not until the third step that you should even consider what the proof automaton will look like.

There's an intermediate step, which is deciding how dependently typed to make your code.  Unless you know what you're doing, the first rule of thumb is that you should never combine your proofs and your programs; the proofs must depend on the programs, but the programs must not depend on the proofs.  (The second rule of thumb is that if you do convince proofs and programs, you must never separate them after they are combined, or must never recombine them after they are separated.  This case comes up when formalizing abstract math.)

After you have decided what theorems to prove, now you must decide how to prove them.  This is best done on a whiteboard, or with paper, or talking with colleagues.  There are a couple different kinds of proofs you might be writing:


are you doing very finicky dependent type hackery?  Use Equations or build the proof term yourself.  (This is not entirely fair to equations, but I think it occupies the unfortunate middle ground of being most useful when you have dependent types that are painful enough that you don't want to deal with them manually, but not so painful that it's hopeless to avoid manual labor)
are you writing a well-defined decision procedure?  Use canonical structures if you want something fast, lightweight, easy to do proofs about, but exceedingly hard to debug.  Use MetaCoq if you want something powerful and general.  Use your own custom reflective automation if the generality of MetaCoq makes proving things too painful (I'm not actually sure how much MetaCoq gives you out of the box; it's plausible that proving things in it is quite easy.)
are you performing long complicated chains of reasoning that don't generalize?  Then write your proof by hand (perhaps using ssreflect).  But also reconsider your decisions about what theorems to prove, and maybe include more lemmas.
are you proving things by taking a bag of tricks and throwing them at your problem again and again until it's solved.  You probably want Ltac2 (or Ltac, if you're not ready to use a language still requiring a great deal of polish, and would prefer instead to use a stable language which is overflowing with quirks).  If you have good tactic hygiene, Ltac is not too painful to debug (and Ltac2 is much better).  The rule of thumb when writing tactics is that every tactic should either do one precisely specified thing (these are tactics like destruct, induction, revert, generalize, rewrite, etc), or should be nothing more than "keep repeatedly trying whichever tactics in this bag of tricks work" (tactics like auto, autorewrite, now, easy, done, trivial, etc).  If you have tactics in the middle-ground, that try to apply this bag of tricks then that bag of tricks then this chain of reasoning and then this third bag of tricks, then you will be in for a rough time.