I like foreign keys, check constraints and tight data types. Might as well constrain it and limit the scope for errors.
Application programmers can write some buggy code. The DB should provide a line of defence.
If you don’t have foreign keys that should be a design choice with a legitimate reason the entity can become orphaned.
You need a definition of what that means in real life. E.g PERSONID id 1012 and there is no associated record. This kinda means you need to look at another entity to know what the first entity “means”.
This might be useful for data that needs to sit in distributed databases.