Is it like, challenging because its an ARM machine? Without the tools something like Android is giving you? I bet it is, because there is a functional Ubuntu (debian) export.
Still I'm not sure what you've all tried internally, but I see things like Windows 10 IOT and Ubuntu images for the Pi. I'm going to start with Raspbian + HTML5 game and see what the performance on that is, maybe see if something runs some other magical way (Maybe WINE or some emulator does a trick? IDK.).
WARNING: Wall of text.
I'm going to try and address the issue of exporting to the Raspberry Pi platform and why it may or may not be a good idea. Having said this, I am in no way affiliated with YYG and have no knowledge of the internals of GMS or GMS2 so a lot of this will be assumptions based on previous knowledge and experience with working with Systems.
Before we delve into technical problems of doing such a feat, let's look at the business end of things. Viability and support, these two key factors are the likely reasons why there isn't an export to the Raspberry Pi platform. GMS and GMS2 as far as I am aware is targeted towards users who would like to create games with ease and deploy them to platforms in which there is a large consumer base. You can argue as much as you want about how many million RPi's have been sold worldwide but the majority of those are to hobbyist. From a market research point of view, this isn't as lucrative as platforms such as Android, iOS, UWP, XBOX, PS3 etc. where gaming is one of the focuses of those platforms. This leads us to the second key factor, support. I am a co-founder of a software company that designed and deployed a portable, scaleable and easy to use grading system for dentistry students at a University, one of the major factors for us when implementing was how we were going to provide post-deployment support for the platform. Now this platform has one use however it needs to work on multiple systems. The problem that arises is, we are a small company of about 4 - 5 employees at any given time, many of us don't work full-time, we could in theory program for each platform and maintain a codebase for each platform, or we could maintain one codebase for multiple platforms. The first option requires us to have support for each codebase whilst the second we only require one. How does this relate to GMS and GMS2's lack of RPi export? Well essentially it's like maintaining multiple codebases, you need a support team behind it, this means more costs overall and over time. In Australia, (I'm not sure about Europe/GB) we have to pay wages based on award rates the government sets. On top of this, we also have to pay for their superannuation, tax and other benefits and to make it even more costly for us, we tend to prefer to find the best of the best to work for us and thus we pay even more above the minimum wage and pay what their worth and so at the end of the day, the cost of hiring a full-time employee is around the mark of 70-80K per annum. This is quite expensive when you think about it and I believe this is one of the major key factors for YYG not to provides the export as if based on my knowledge and experience, it would cost roughly 320K in support costs over the duration of the software.
Now onto some technical things about creating an export option for the RPi.
One of the amazing things about the RPi is the fact that it's affordable and allows hobbyist to tinker in the embedded world without to much of a hassle and crazy learning curve. The other amazing thing is the fact that you can load multiple different operating systems onto it, Ubuntu, Fedora, Debian, Arch etc. You name it, there's probably a way of getting it to work. But this flexibility does pose issues for an export component in GMS and GMS2. One of the first questions, I would ask myself if I were doing such a component would be, how do I support all of these different operating systems? and secondly, if I'm to support just one, which one do I support? In theory it's not all that hard to create a cross-platform codebase, ensure you use libraries available on all platforms and don't do any tricky things... here's lays the issue, for a simple program, that's possible. For a program like GMS/GMS2 that's not quite as possible. I'm not sure what graphics library GMS/GMS2 uses on the back end but I can name a few that I'm certain it employs and those are OpenGL, OpenGL ES and WebGL. If you've ever worked with OpenGL directly, you'll understand that it can be a pain in the backside to get it to function exactly the same on all systems and that's between Windows, Ubuntu and MacOS each one of those requires different headers and if you decide to involve GLUT, you'll have to pick between all the different unsupported or barely supported GLUT libraries. Oh and heres the catch, some features of OpenGL might not be available on different platforms and this is just OpenGL, what about sound, what about networking? There's a heap of individual components to get right and then after that, you need to get them all to work coherently together.
The other place in which might be a problem is the interpreter/compiler. I assume GMS/GMS2 compiles to bytecode and so YYG will need to build in support to their compiler to have it translate GML into working ARMv7/6/5 (Or whatever the RPi boards are) byte code. Other things it will need to do is expose the on board hardware components to GMS/GMS2 in a safe and secure way, such components would be the GPIO pins, Camera etc. These are whole new set of functionalities that GMS/GMS2 will need implemented and trust me, it's not a small task.
I haven't really gone overboard in the technical side of things as I'm trying to keep this to as simple as possible however if you're really interested in the obstacles one would encounter, you should study Systems Programming (The University of Western Australia has a very good set of lecture slides available to the general public. If you google UWA CITS2002 you should get last years course material however that may be changed soon as the new semester starts and they will reset the information).