The compile-time unit test point is the one I would lead with if I were rewriting this, because it is the part people underuse. Getting UB caught at build time, purely because the constant evaluator is not allowed to have any, is closer to a free sanitizer than to a test, and your divide(10, 0) example makes it land in about four lines.
One thing worth fixing in the lookup table example, because it is the exact place this bites people and the reason is more interesting than a typo. ComputeFibonacciLookup returns a std::vector, and storing that result in a constexpr variable will not compile. A new expression is only allowed inside a constant expression when the storage is deallocated within the evaluation of that same expression. std::vector became constexpr friendly in C++20, so you can build one, use it, and let it die inside a constant evaluation. What you cannot do is let its allocation survive to runtime, which is exactly what a constexpr variable asks for.
You state the rule yourself further down, when you mention the compiler checking that you deallocate properly. Connecting the two is worth a line, because the model most people leave with is "C++20 gave us constexpr vector" and then they hit this on the first thing they reach for, which is almost always a lookup table.
For the table itself, the shape that works is a std::array with the size as a template parameter, filled by a constexpr function and returned by value. Nothing is allocated, so there is nothing to deallocate, and the table lands in the binary as data. std::to_array helps if stating the size twice is annoying.
Non-transient constexpr allocation has been chased through committee papers for years and is still a paper, so this is not a case of waiting one standard and getting it for free.
Small thing: the static_assert line reads FIT_LOOKUP_TABLE.