Partition type FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, drive unmountable
The volumes could be recovered in a TeamViewer session by searching for special strings similar to the method outlined in this answer: My SATA hardrive was ejected, and is unable to be remounted due to issues.

The assumptions made:


disk3s4 (24.6 GB) and disk3s5 (650 MB) are located at the end of the disk (see diskutil list screenshot of the question - both vanished after destroying the old partition table with sudo gpt destroy /dev/disk3)
disk3s2 (Macintosh) occupies/occupied the whole unallocated disk space (except the 1st Recovery HD) of ~294 GB and is encrypted.




To get the starting block of the first Recovery HD enter (which has to be in the 271 GiB - 274 GiB or ~291 GB - ~295 GB range of the disk)

sudo hexdump -s 271g /dev/disk3 | grep "48 46 53 4a"


(hexdump uses GibiBytes instead of GigaBytes!) which revealed:

447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...


0x447f801400 is Byte 294196876288 (or block 574603274) of the disk. Since the string HFSJ resides in the third block of a volume, the Recovery HD starts with block 574603272. 

The typical output if the previous volume wasn't a FileVault but a normal HFSJ volume would look like this instead:

447f800c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 01 ff
447f801400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f828a00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
447f840c00 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 00 06
447f871e00 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 00 06
...


The first and second byte number show a difference of 0xc00-0x1400=0x800 or 2048 Bytes because the preceding OS X volume has an alternative volume header in the second last block while FileVault volumes don't have one.

The Recovery HD has a fixed size of 1269536 blocks and it can be added with gpt to the partition table.

sudo gpt add -i 3 -b 574603272 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk3


Now verify the volume with

diskutil verifyVolume disk3s3


If the partition boundaries and the volume are/is OK you'll get an exit code 0.

In the unallocated disk space between EFI and Recovery HD a CoreStorage partition was added:

sudo gpt add -i 2 -b 409640 -s 574193632 -t 53746F72-6167-11AA-AA11-00306543ECAC disk3


The FileVault password window popped up and the password was entered - so it  was added successful probably.

The disk and the volume were verified with:

diskutil verifyDisk disk3
diskutil verifyVolume disk3s2


which both exited with code 0 and all was fine.

Later the FileVault volume was extended to the full size of the disk with:

diskutil cs lvUUID resizeStack 318g #with lvUUID: the Logical Volume UUID of the second CoreStorage container