This problem often occurs when the implementation was run by an internal IT team who have traditional SQL skill sets. They will create a custom object for every single enumeration table they think is needed without regards to how SFDC relational data models actually work (picklists for example).
This leads to headaches when building standard reports, and usability issues when viewing and editing data with standard SFDC pages. For the above example the mult-select picklist for "Payment Options" would show up as a Related List, and the Marketing Status would show up as a Lookup. If we created this same data model in SFDC it would look like this:
And this would manifest itself on the Standard UI as this:
Not to mention they can't easily filter on Payment Options for List Views and Reports.
This can easily be corrected by using picklist and multi-select picklists in SFDC. If we use those types of fields our data model removes those 3 objects and everything resides on the Company object. The correct data model looks like this: