Performance impact of NOT using a foreign key (many dedicated 1:many key-key tables vs non-fk generic key-key table)
It looks to me that you are considering the EAV (Entity Attribute Value) model, i.e. wedging every object into a single table, rather than having different tables for different objects. EAV is generally considered an antipattern. 

It can be known as an Open and/or flexible Schema. It is also known (sarcastically) as the OTLT (One True Lookup Table), (even more sarcastically) as MUCK (Massively Unified Code Key - Joe Celko) and perhaps best of all (I only just found this) as DEMONS (Diabolically Enticing Method Of iNformation Storage - adapted from Mike Smithers).

It is interesting to note that Celko (who was a member of the ANSI/ISO SQL committee which determines/ed the SQL standard) said (see reference) about the programmer who had written such a system that the questioner should "Find the moron that did this to you and kill him". 

See the Smithers' post (and and Celko's writings here and here) about the difficulties of writing queries against EAV schemas. It's no coincidence that Celko titles his first article "Avoiding the EAV of Destruction". Take a look here for an absolutely hilarious visual analogy of the EAV system from Bill Karwin - a highly respected SQL guru and author of a book "SQL Antipatterns". 

You mention "having defined foreign key relationships in smaller tables, but potentially hundreds of them". Modern RDBMSs can cope with hundreds of tables and FK relationships between them and unless you have VERY strong reasons (with proven testing behind your argument), then stick with traditional relational principles.

To directly answer your question, in all likelihood, the complexity of the queries that you will need to use to obtain data results from an EAV system will have FAR more of a negative performance impact than a system with many tables with clear, properly defined FK relationships using INT(11) foreign keys or even UUIDs.

Another point about performance - use of an EAV system will force you to use inappropriate datatypes and this will seriously interfere with your RDBMSs query optimiser's ability to (err...) optimise the queries. Under these EAV systems, many values are (again inappropriately) stored as strings and converted on-the-fly, which is both time-consuming and, again, confusing for the optimiser - not recommended.

From my accepted answer here and for completeness and honesty, just one further remark. There is only one significant system out there that makes use of the EAV model - and that's Magento (1, 2). Its principal niche is the fashion industry where the EAV model may be suitable for sparse tables (fashion items tend to be available in a myriad of colours, syles, sizes...). It is popular (1, 2), but then so is MySQL which is inferior in many ways to PostgreSQL, Firebird and (multi-user capability aside) SQLite.

I also noticed this in the comments 


  but I never rely entirely on the DB's RI, I generally do it at the
  application layer falling back on RI as a backup. I've considered
  using a maint task that runs occasionally to remove orphaned records
  to shore that up as well.


This is nothing short of madness. 

The RI (Referential Integrity) capabilities of MySQL (and other RDBMSs) have been tested by literally MILLIONS of users. If you set up a proper PK-FK relationship between two of your tables, then the chances of this failing are virtually NIL! You'd be far better off using your time and effort to focus on other areas of your application than ensuring proper RI - unless you've committed the unpardonable sin of implementing RI in the app rather than using the capabilities of the RDBMS. See Jonathan Lewis' disaster no.2 in my answer here. Lewis wrote this book, so he knows a thing or two about databases.