So any code, gate patterns, or microcode (preinstalled or not) that is potentially update-able (regardless of difficulty) would be considered "software". But any code, gate patterns, or microcode that is preinstalled into some rom or fuse memory inside the chip or that is otherwise impossible to be updated would be considered "hardware".
If an entire OS microkernel (like seL4) is burned into some rom inside the same chip with cpu and is physically impossible from being updated, it would be considered hardware by this gnu.org definition, but should be considered software according to wikipedia's definitions:
"[Software] is any set of machine-readable instructions that directs a computer's processor to perform specific operations." "[Hardware] is the collection of physical elements that constitutes a computer system."
Theoretically anything in software can be implemented as hardware and vice-versa. But should updateable-ness really be the differentiating factor? Now lets say that seL4 was compiled into VHDL to put in a fpga. (I am using seL4 as an example because it is small and written in a functional language which would be easier to implement in hardware than a macrokernel written in a sequential language like C, and because it performs a significant function of a computer, even though it may be impracticable to implement in a hardware description language). Is that hardware or software now? I would say hardware, because it is now a collection of physical elements connected together. But gnu.org's definition only seems to care about the updateability-ness.
What if instead the seL4 code was on a rom that couldn't be updated internally, but could instead be physically removed from a socket or unsoldered and replaced (even if not intended to be). I'm not even sure whether this gnu.org definition would consider it hardware or software, but I would guess using the strict updateable-ness criterion alone, by having some manner to be replaced, it would be considered software.
Sometimes organizations choose definitions to provide realizable goals. FSF uses this updateable-ness distinction, and then can for example say that the libreboot X60 runs entirely free "software". But of course my libreboot X60 has a bunch of processors running un-updateable proprietary code, such as the wifi, disk, and graphics chips, even though they are interfacing to the cpu using open source drivers. Also FSF seems to tolerate the preconfigured microcode already on the cpu, but won't tolerate microcode updates loaded at boot. But by using this non-updateable-ness criterion, FSF has a much more manageable but achievable conditions to meet the goal of free computing rather than having to "free all the things".
Maybe FSF is attempting to find definitions relevant to libre-ness. But I don't think making up their own new definition of hardware and software is necessary for achieving goal of free computing, nor terribly useful. I think they should just stick to the 4 freedoms (to run the program, to study how the program works, to redistribute copies, to improve the program) and might be better focusing on using the word "program" instead of having to make up their own new definitions for hardware and software. The word "program" transcends the distinction between hardware and software.