Linux in embedded systems main appeal is time to market and ease of use. From a hardware stand point there is a decent amount of support in terms of kernel modules and device drivers. From a software perspective it has a large number of stuff such as filesystems and networking along with various packages that can be installed for ssh or cryptography.
This basically accelerates development. Linux is also a full operating system which supports multi-threading/processing. This can allow a decent amount of developmental comfort to be passed on. The Linux kernel supports a wide array of hardware but isolates this from the programmer to a large extent unless your doing serious kernel coding. Which for most of the time I am going to guess it will not be common outside of a few specific areas.
So far this sounds really awesome right. However the catch is mostly as seen in the linked article. Linux is not actually super low level, its an operating system. Linux is designed to work in environments which are not real time. What a lot of people have done is bought their way out with faster hardware, which lead to power consumption issues. This is part of the love of ARM to which is supposed to be pure magic.
You will find the weaker members of the embedded community are very opinionated and love three major groups. These members also tend to have little insight into what they are doing or what is proper for this context. These groups are Atmel, ARM, and Linux fanboys. You will generally hear them talk about the development support and debugging options. Most of this is for people that are not trained or accustom to this context/environment.
Linux is like high level programming for hardware. Which is why people generally attempt to classify this as low level. This of course fails. However areas of concern here are memory management and process/task management. Programmers that struggle with pointers will struggle with bare metal programming. Which is a major motivation for using Linux. Simply put there are many programmers that could not work in that area. Just like Java was created because people could not use pointers, unsigned, memory management, etc.
Now there is one area that really shocks me. Linux generally speaking is not known for security in IoT. The reason for this is not so much due to Linux itself but the large context of Linux and improper understand/application of it. Linux standardizes the security footprint and allows assumptions to be made for hackers. Along with a programmer doing stupid things can basically create a side channel for exploitation. The massive amount of reuse in Linux and the ecosystem can promote a culture of insecurity which can have huge ramifications under the premise of IoT.
Even more shocking is the whole notion of embedded Linux to begin with. Here the abuse is the notion of embedded which generally implies specialization, whereas Linux generally implies general purpose. Embedded systems as part of their specialization generally work under real time constraints. However Linux does not. RTOS is supposed to be used here. Granted the Linux kernel has a patch which can be applied to bridge the gap. However overall Linux has a lot of overhead due to the large general purpose support it carries. This can cut into the RTOS behavior. Granted Linux is modularized and kernel programming is available. However following that would be following bare metal which begs the question of why?
As for ARM itself. Look this mostly a feature of fad culture and ignorance mostly. Linux did recently trim down support, which makes some sense and is confusing at the same time. A lot of what surrounds ARM is BS. I generally look down on "engineers" that go over the top with singing ARMs praise. Personally I think they miss the point of the context and lack understand of hardware, architecture and ironically software. Everyone was so shocked when ARMs power yields against frequency fell off, but anyone familiar with hardware knew this would happen due to dynamic current.
I personally do not like ARM or embedded Linux too much. The reason is people are too likely to push pure software which is very inefficient or push something like Java or Python. Which we have already seen. ARM cores enable most of this. ARM cores also are rarely implemented in a Harvard configuration outside of the core itself. Granted many higher speed processor don't do this also. However options do exist for this, but rarely do. Again with hardware software co design and SoC based designs most of this should be changing.
This is kind of the issues with the whole PIC vs AVR war. Sure the AVR may be faster, however there are contexts for which this simply put does not matter. An engineer had better know this. Engineers should be the only ones in this space, as CS has shown complete disregard for basic theory and conceptual stuff learned in the second year of college. I view the promoting of embedded Linux as something a CS person would do rather than an engineer. CS as a field has entered a very strange position in the world. It believes it can do anything, but is bad at it. It also has moved away from more productive in devours. Engineering will have to sort that out later on. Of course I am referring to AI, which is not new at all.
Interfacing with an FPGA is a very open ended topic. FPGAs do not really have an interface so you can make it do whatever you want. If you have a Zynq you can use an internal interface to bridge between the ARM and some custom hardware perhaps via memory or AXI. Then there is external interfaces like SPI or PCI/PCI express. Driver development for something like Linux will depend on this interface and the platform you are using. For bare metal its a little more straight forward as you are basically working with an IO module.
Now I briefly mentioned that it was possible to use Linux for a custom module in a FPGA. However I also mentioned that Linux is poor for real time performance. Why would I say that then? Well the answer is it would depend on how the design handles this. For example the hardware does everything that is real time. The Linux part only handles say a configuration component which is TLS or a web server. That Linux part can be slowed out of real time, as the actual operation will happen concurrently in hardware without restriction. The same is not true with pure software. Granted you could use multiple software processes, but then you get into cache issues, memory bus problems, etc.
In summary ARM is loved for its support. Linux is loved for its support and cost reductions. Which mostly has to do with labor and time reductions. However proper design and support is usually compromised under this. Arrogance is extremely common.
There is now a light switch running cell phone grade hardware. Why cause it needed Java for some AI component. It runs off Android which is based in Linux. Welcome to 2019. Were inefficient is efficient. Were we need to do better to save the planet but screw it over doing this. The guy that made that will be declared smarter than me, yet I may know more about this than him. He may even have a PhD. After all this is so low level. So I would say these people are amateurs rather than engineers. You cannot really have this discussion with an amateur. (That is my foolishness.)