Let's quickly start with the general purpose of the OEM environment: it allows the creation and customization of a single machine or a small batch of machines at a time. This is (relatively) similar to the Windows concept of audit mode. A typical OEM workflow would look like this:

1. An OEM boots up a device and installs OEM mode to the device.
2. The OEM will configure the device, install any applications, load drivers, so on.
3. After configuration, the OEM will prepare the device to the end-user for shipping. The system will shut down/restart. [I assume this was the step that the user ran, triggering this entire situation.]
4. If the device is a "gold-master" and is part of a larger batch of devices, the device will be imaged out and cloned to other devices.
5. A prepared device is shipped to end-users.
6. The user receives a prepared device, turns it on, and goes through OOBE setup (username, password, etc.).

Most home or small workshops offering Ubuntu installation would use OEM installation on a per-device basis without any imaging. The end user would receive the device, and on first-boot they'd be prompted to create their account and configure everything.

So, what happens to the oem user when the device is prepared for shipping? Well, when a device is prepared for shipping, it kicks off a number of tasks that delete the OEM user and prepares the environment (uninstalling packages, updating systemd unit files, and so on). All of the scripts for preparation are located in /usr/sbin/oem-config*, and can be viewed here. The user is them dumped back into Ubiquity (the setup screens), where they go through account setup.

The bad news here is that all of these tasks are pretty write-intensive. A lot of the (recently-)freed blocks that was occupied by /home/oem will now be used for the new user's configurations and the changes made by the new system and the OOBE configurations.

With all this being said, you're fighting an uphill battle trying to recover this data. The files lost are (relatively) small, and as such are very easy to get overwritten when the new account is created. Tools like photorec/testdisk and autopsy would likely be your best bets, as you've already tried. If these tools can't recover anything, there likely isn't much more that can be done save for some very expensive and/or very powerful recovery tools that people don't usually have access to.

You did mention the existence of a /home/oem file as well as a folder. This may be causing data recovery tools to get a bit confused - a file can't have subfiles, so any attempts to piece together a file tree will fail at this point. When running a disk recovery tool, be sure to look for any files that are "orphaned" or otherwise don't belong to a specific directory.

I'm going to go back to my recommendation from the comments of using photorec. Instead of focusing on partition- or filesystem-level recovery like testdisk, it tries to pull and recover individual files while disregarding the directory or filesystem structure. This is suboptimal (paths and potentially file names are lost), but having the raw data recovered is better than having nothing recovered. I suspect autopsy has a similar "miscellaneous" output bin, but I'm not familiar enough with the tool to tell you where to look for that.

If photorec can't recover the files themselves, it's likely that they were (mostly) overwritten during the personalization phase initiated by the user. In this case, it might be best to contract the services of a data forensics expert with access to the necessary tools and knowhow to recover data like this.

The good news first

The good news is if User OEM was deleted and a new user was created in it's place then the skeleton files created would hopefully be the same size as the skeleton files deleted from User OEM. Then if new user didn't create any new files besides that, the new files created by User OEM would hopefully still be on the disk in abandoned sectors. Hopefully the only OEM files lost would be OEM skeleton files simply replaced by new user skeleton files in relatively the same locations. Underline "hopefully"....

And now the "But..."

It would certainly be a lot of work to recover the data. If you are interested in the .odt files you'll first need to find a string of characters to represent an .odt file. For example:

$ ll Double*

-rw-rw-r-- 1 rick rick 192599 Mar 18  2018 Double suspend.odt

$ head "Double suspend.odt" -c 400

PK��rL^�2
           'mimetypeapplication/vnd.oasis.opendocument.textPK��rL���A�#�#Thumbnails/thumbnail.png�PNG

So I could grep my hard drive (you can't use this method though) for all files with the string "mimetypeapplication/vnd.oasis.opendocument.textPK":

$ time grepall "mimetypeapplication/vnd.oasis.opendocument.textPK"

Binary file /usr/share/cups/data/form_english_in.odt matches
Binary file /usr/share/cups/data/form_russian_in.odt matches
Binary file /usr/share/doc/fonts-sil-abyssinica/documentation/AbyssinicaSILGraphiteFontFeatures.odt matches
Binary file /usr/lib/libreoffice/share/template/common/internal/idxexample.odt matches
    (... SNIP ...)
60.47user 22.74system 2:23.48elapsed 58%CPU (0avgtext+0avgdata 20788maxresident)k
61233744inputs+0outputs (0major+8533minor)pagefaults 0swaps

real    2m25.881s
user    1m0.507s
sys     0m22.759s

Now instead of using grep you would have to use a tool that searches every byte of your hard drive whether it is part of a file or not. An example would be tools in this closed Q&A:

• Linux search entire hard drive hex bytes for byte string and list all files the data belongs to?

Then there are other tools:

• How to recover deleted files?

Finally if you had just written the new Microsoft DOS 1.0 and lost the only copy of the assembly code you could use a data recovery service. Which you can google for. Finally consider this article:

• 7 of the Best Data Recovery Tools for Linux