OK, so based on the various discussions, I think the consensus as to what applies in the situation is this:
First, we note that sizecoding questions are on topic, but hard to write. See this meta thread for more details. (Thanks to mınxomaτ for suggesting the link as relevant.)
There are two specific reasons that sizecoding questions are hard to write. They both stem from the fact that the optimal solution typically involves writing the machine code first (even if you originally wrote the solution in some other language, you'd gain an advantage from taking the resulting machine code and micro-optimizing it by hand; most compilers tend to be fairly bad at golf).
One issue is that the language in which your program is written tends to be irrelevant when all you're looking at is the compiled output. Nifty/clever use of language features, which is one of the motivating reasons that many people come to PPCG, is irrelevant because you could do everything more easily in assembler or even literal machine code; unlike typical programming, writing in a higher-level language makes things more difficult rather than easier.
The other issue is that the source code of your program tends to be irrelevant when all you're looking at is the compiled output. There's no benefit to saying anything in a terse way or avoiding redundancy (at least if the redundancy can be detected by the compiler). A good example of this is asm.js, a subset of JavaScript intended specifically for the JIT equivalent of sizecoding (typically by compiler output); it doesn't look anything much like regular JavaScript and is highly repetitive and hard to read.
The challenge that inspired this question happens to work around both these problems:
One way to make the language choice for sizecoding interesting is to score the size of the program on a range of different processors without allowing processor detection at compile time, thus requiring the program to be portable, and meaning that it can't rely entirely on hand-compilation but has to use actual features of the language's compiler. Doing this explicitly for sizecoding questions has the issue that scoring an answer will be very hard. However, the linked challenge does it implicitly, in that it requires output intended for an FPGA; unlike CPUs, which have a few very widely used models, no model of FPGA is popular enough for it to be easy for most people to optimize the code specifically to target that model. As such, it's going to be much easier to write a portable submission that should sizecode well on a range of hardware, than to track down a compiler for the specific model in question and see what results it produces (especially because some compilers will be better at optimization than others).
The question requests the competitors to write a quine. This implicitly gives an advantage to simpler source code, because encoding the source code in the output will require less compiled size, and thus makes the source code relevant indirectly. In this particular case, it meant I wrote a solution in Verilog rather than my (usual choice for hardware questions) VHDL, because Verilog requires less boilerplate (VHDL is sort-of the Java of hardware description languages). This made the problem function like a more normal problem in terms of effort required in language selection and program optimization, thus getting around the problem.
It seems as though the scope for good sizecoding questions is fairly small; in the majority of cases, we'd be better off with a code-golf with a winner per language, and having machine code as one of the languages to compete in (especially as it tends to be a fairly competitive, if not widely chosen, choice in code golf questions!) It's definitely not the case that such a question is automatically bad, but on the other hand, it's unlikely that we'll get a sufficiently large number of quality questions on the subject that having a unique tag is worthwhile.
As such, questions which request a minimal compiled size, which is an objective and uncommon win condition, should be tagged code-challenge, like other challenges where the win condition is objective but unusual.
