I know I don't understand the domain at all, but I'm surprised that in this day and age you'd want a distributed system to do railway design. What aspect of the problem makes it unsuitable for running in a single process?
Additionally, the UI contains complicated elements such as custom maps with the railway network and custom graphs to visualize trains. There is a large ecosystem to implement this kind of stuff via Web technologies. A webapp also removes the need to distribute an installable binary on many different platforms (some may be quite restricted due to company policies) and many different machines (there are many users, see above).
Note that the system uses a client-server architecture but isn't really distributed.
Yeah, I kind of agree. The thing is, it's orchestrating multiple containers to do the job. I can't figure out why you couldn't just have one container.
(Of course, it's completely possible to build a single container which runs all of the services in parallel, but then monitoring/scaling/availability/etc are more difficult to handle.)
Having done both, I'm always surprised when people say that it is more difficult to handle running N-copies of the same container than a heterogeneous set of containers. Sure, at really large scale you can glean efficiencies from it (which is why one might do it), but there's a lot of complexity that comes with that.
Modularity of code is a common explanation for using a multi-service architecture, but it's not a particularly strong one (services are just one way of modularizing code). In terms of OSRD services being accessed by external applications, it doesn't seem like that would work particularly well, given the coupling between the pieces. The only pieces that would make any sense to me for outside applications to directly in would be the PostgreSQL database... and if that were the plan, I'd just host the whole thing in PostgreSQL.
EDIT: The goals of OSRD include realtime cooperation between multiple entities, including timetabling and planning on short term. Thus somewhat more complex application that is "multiplayer".
Part of the issue is that desktop application delivery can be troublesome, logistic wise (especially now with various cross-platform environments dying off), so if you want to serve as wide group as possible with minimal logistical hassle, web might be the way.
Then you might end up building it multiprocess because it's not like you have a monolith once you have complex browser-side state...
Could it just be the skillset that government has to? Web devs are a dime a dozen and you can probably find people to maintain/incrementally upgrade parts of it in the future easier than you could find an expert in some desktop GUI language (like .NET or Swift) that would still work after a few years of OS updates.