Can anyone suggest why a desktop PC could be considered vulnerable to Log4J ?
This is a complicated topic, and if you're not a Java developer a lot of it might seem over your head and esoteric. It's hard to even talk about it without assuming a certain frame of reference in common, but I will try and give some background to help.
First, what is a logging system, and thus what is Log4J, and why does a developer add one? When you're developing a program, there are many levels of output that you might like to see during development, but you might not want to bother your end users with when the program is finally delivered. A logging system allows the developer to classify a debugging message with levels, such as ERROR, WARNING, INFO, DEBUG. The system itself is also configurable as to which level of messages are output. Additionally, the logger can be configured as to the style and formatting of the messages as well as where they are produced or saved. It can be configured to output to the console or to files (frequently rotated so only so many collect and thus only so much disk space is used for logging.)
The theory of the design is that messages that are not enabled have a minimal impact on the speed of the program that is thus not outputting them (when they're configured off.) This encourages a developer to add these messages when needed, but not have to remove them when development proceeds further. (The developer can leave them in place but configured off, in case s/he needs to come back to that code for further debugging later.)
One hallmark of Log4J is that it can usually be very easily configured with a single system wide configuration file (often in XML but these days other choices exist.) This means that it can be part of almost any piece of code that ever needed debugging, but configured to do nothing. If it's not doing anything in the overall system it's part of then it poses no risk to exploitation by Log4J vulnerabilities. (It should still probably be updated, just in case, and to prevent false alarms by detection systems looking for old potentially vulnerable code.)
As for your original question: it would depend entirely on the software running on the device. Log4J is a sub-component of other software and does not normally have an incoming connection from the network. It would depend on what program was using it. In order for the exploit to occur, and attacker needs to supply input to a program that the program itself will then subsequently supply to an enabled Log4J outputter.
Presumably the scanner can recognize the blob of code that is Log4J (a binary set of Java class files) but not recognize what it is being used to do. When building software in Java, it is very common to use a hierarchical build system that knows about dependencies of sub-components. A logging system like Log4J is very frequently a dependency of other software which gets included if you're building a program and want to make use of re-use of existing code rather than writing all of it on your own. If when present, it might not be configured to be enabled, or if enabled, there might not be a way for the attacker to pass input through it.
As an example, let's pretend you want printed reports out of your Java program, so you use a PDF generation tool that is freely available. The developer of that PDF generation tool may have built it to include Log4J to help with that developers testing. The PDF sub-component will not ship with a Log4J configuration file, so no logging will be done by default when it is included with your code. If you, as the developer of the tool that uses the PDF sub-component, configures logging as well, then you may or may not have the information you need to enable the logging in the PDF sub-component. In any case, the code will be present (because it is a dependency and will not build without it) but if it's not used by the higher level, code, it's not posing a risk. If it is used by higher level code, but that code doesn't output any user input, there is still probably no avenue for an attack. It needs to be the case that the program using Log4J is also somehow allowing user controlled inputs to be passed through to Log4J for output before there is an actual path of attack.
