To be fair, it is almost impossible to get data out of SAP. Their "security" is all there to prevent users from doing anything useful. You have no access to the underlying database (like DB/2, oracle), you have to use their GUI or write a custom ABAP program.

But in most cases, the functions you need to call to write data to disk are usually closed off to developers due to "security". If you have access to the database (almost impossible to get), the data for the important tables are spread throughout multiple tables with names that look like names created from /dev/urandom.

I am familiar with SAP, all that you say is only true if you don't know how to do it. I see this a lot, people that are familiar with "normal" technology, try to invent ways to do things in SAP. What is wrong with writing an ABAP program, or using a provided communication/interfacing method to transfer data? If you are stuck on GUI/files/DB level, sure you wont be able to do anything. You can for example generate complete excel files on the server, no need for the GUI. There is a running joke on SAP forums about how many times excel file generation was invented.

Some of the cryptic table names date back to R/2, sure, but they are the de-facto standard data model for those business data. If you have business systems communicating, for example product, business partner or financial data, it will have a mark on it of how those data are handled by SAP.

But then there are CDS views (for some time now) that have long descriptive names, and metadata to help you make database queries. You are not meant to read or write database tables directly (as of some time).

Again, I will say, where I worked, due to "security" lots of items were disabled, even for developers. The only item that you could use to get data was SE17, some people (a few) were allowed to have SE16. But due to memory, getting data that way was very slow.

Also, SE16 did and may still have security issues. That was the reason for it being disabled for 99% of the users.