I’m going to answer this in a relatively long way to be informative since it might be interesting for the people who are interested in this thread.
For the ones who don’t want to read, yes it is possible but there is much more to it.
What exactly is sysex?
Think of sysex as a packaging around a hidden surprise present.
It always starts with 0xF0
continues with some metadata which are public to everyone such as manufacturer id and some more identifiers then you reach the present: “some data” and finish with 0xF7
.
The some data part has a special encoding (7bit encoding) which is the second property which defines sysex. If you’re interested, read more about the standard structure here.
In short words opening the packaging of this surprise present and seeing what is inside is trivial.
- You read the header (meta data)
- You decode the data which is a common and known process
Now you have this surprise present in your hands. The only thing is, you don’t know what it is good for, you don’t recognize that object. That is the point where reverse engineering starts. From here on I’ll move on from this analogy and call this surprise present data.
Sysex is just a packaging over the data which can mean anything since it is just numbers.
Your shopping list, analog rytm pattern or Windows 10
.
Sysex dumps
Fortunately when you have some context over what you’re receiving or querying and the data you’ve received is expressing some settings or parameters but unfortunately not documented you have some chance to figure out what it represents in a reasonable time frame with clever manual labor.
For example, when you know that the data represents an object in a rytm project, since you have a concept in your mind about what a rytm project contains you can make come up with a system to request parts of that project again and again while changing some values (simplifying) in the device per request and compare the response with the previous one to figure out what parts of the data change in this process. After some time the model of that data emerges. Then you may express that model with a programming language.
The key point is that the data comes with the sysex dumps which are already made available to the user has a defined context and we know roughly what it should contain.
To give you an example:
Here are two tracks in the data which comes from a pattern request from rytm. I’ve colored parts to figure out and focus to them individually. See that the colors repeat, probably you can even spot the track boundary.
The OS
When it comes to the OS it is a very different story.
If our surprise package contains an OS, it is not meant to be known since it contains a significant amount of intellectual property which is held by the company accumulated over many years.
Another thing is, while sysex dumps contain a list of parameters about an object i.e. pattern, the OS contains an executable file, a program for the device’s micro controller chip to execute.
A computer program is made of machine instructions which are again numbers like you see in the picture but when a processor (CPU or Micro controller) reads them it interprets them as actions, instructions. There are thousands if not hundred thousands of those instructions in an OS.
For the worse, those instructions are not written by humans, humans expressed the OS logic in a programming language such as C, C++ or Rust. Then they ordered the computer to translate it to those list of instructions which are called the machine code (processor type specific language). The process of translating the human readable programming language to the machine code is called compilation.
Enter decompilation
Now that we have the context. How can one disassemble the OS data to figure out what that means?
With the OS’s of today’s scale this would take years of error prone and tedious work to do manually. It is almost impossible.
This is why people created programs for decompilation and reverse engineering executable files such as ghidra.
But those programs are only a tool and a lot of creative guessing, trial and error, is necessary to decompile an OS completely which would take months.
I mean decompiling the rytm os and changing the start logo would be a fun task for a researcher and I think it is quite possible to do in a short time. On the other hand decompiling the whole OS and have control over it to develop it further or change it is a task of a completely different scale.
Imagine the functionality in Rytm from controlling the analog synth circuitry to sampling, effects to pattern management, menus to audio rauting, overbridge support… I can keep counting.
You need to understand how all and more of those components behave together in a high and low level way, also control or develop them without any documentation and no one to help you. It is a daunting task. You can come up as a team of individuals to do this but then maybe it might make sense to make your own product 
Legal concerns
Decompilation itself is not illegal. You can try to do this for research. On the other hand exposing Elektron’s internal source code would be. The reason is you’re sharing intellectual property which is not meant to be shared. Many programmers earned good amount of money over the years to create that property and actually Elektron owners have obtained that property in a very financially heavy way. That can get you in trouble.
After 10-20 years when the product becomes vintage… probably not that much but that is a speculation. 
I’d say reverse engineering the OS would have been an interesting research project but doing something useful for the community with it such as a modified or alternative OS is extremely difficult, theoretically possible but practically wouldn’t worth it (opinion) at the time of this message.