Unlike older cartridge based systems, the PSP loads everything into RAM. The disc is only accessed through function calls.
The primary binary (EBOOT.BIN) is loaded to RAM with its BSS etc., much like a program on PC. Typically (basically always), this will start at 0x08004000.
Many PSP games use relocation, but I think Tales of Rebirth doesn't. Because of that, global variables are probably hardcoded addresses.
But because memory is dynamically allocated (and can be consumed by plugins, or video player libraries, etc.), games very rarely hardcode memory addresses in files on the UMD. Instead, you'll see offsets into memory from a base or offsets into the file data more common - honestly, a lot like PC.
For example, games may have a file with strings for a certain area, with a table in the beginning that points to each table (by file offset.) Then, strings may be referred to in some other file by bytecode/scripting/whatever by their numeric offset into that table (i.e. string #5.)
More importantly, games often use "virtual filesystems". It's a bit annoying. In the case of ToR, I assume DAT.BIN and FLD.BIN are some form of this. On startup, basically the first thing the game does is open these files, seem to 0x3FF400 in DAT.BIN, and read an image (maybe the boot logo?)
So offsets in the file are probably hardcoded in the binary somewhere. Then offsets into those subfiles (to the actual strings you found) are probably next.
The UMD was slow and the PSP had a decent amount of RAM (considering, 24 MB user RAM isn't a lot but it's way more than the GBA or DS), so games would typically read whole chunks. It's unlikely it reads each string one-by-one from the file or works in direct offsets to strings within the file.