I've read that it is better to implement down counter because when implementing up counter you need one additional comparator and one additional adder so you would use less resources by making down counter.
Since FPGAs don't contain counters and comparators, but LUTs, this approach doesn't tell us anything!
However, I think you might be missing some context: the idea is that a downcounter always stops at 0, which is a really easy value to detect. What differs depending on how "far" you want the thing to count is the value that's loaded on reset. And loading a value once every reset is less complicated than comparing all bits of your value against the counter limit.
That being said: I've seen many up-counters in actual FPGA HDL designs. It's really not like a comparator would be expensive – honestly, for example, a series-7 Xilinx FPGA has 6-input LUTs, so for counting to something with up to 18 bits, you can do it with 3 LUTs, all of which you find in a single slice(m). It doesn't get any combinatorially "flatter" in hardware, so honestly, this might be optimizing the wrong thing: such an FPGA detects "18 zero bits" exactly the same way it detects "0x3CDEF", by feeding it into three 6-bit LUTs.
Your reasoning becomes valid for devices with fewer LUT input bits per slice, i.e., when you need to add combinatorial depth to implement the comparison or start consuming a lot of space for the fast comparator. But even in "simpler" FPGAs, the logic blocks (or whatever what are called "slices" by Xilinx are called by others) often have "carry-over" inputs and outputs, to enable exactly that: putting an array of LUTs next to each other, and combining their output in a highly-clockable way. I don't know, but if I had to take a random guess, summers and counters are exactly the reason these are so common.