I am modeling Contacts for a mobile chat app that sources its contacts from the OS contact book (iOS/Android).
A Contact can have many phone numbers (ContactPhoneNumbers).
Instead of having the Contact table and doing a join (A), I am exploring merging the Contact attributes into ContactPhoneNumber (B). I could then directly fetch a user's ContactPhoneNumbers, and already have all the contact's information, since duplicated on each record.
What would be the downsides of doing B instead of A?
RDBs are purpose built for creating relationships between the entries of tables. Normalizing data and creating relationships between tables allows you to ensure data integrity. By avoiding those tools, when one of those denormalized data points is updated, you must update all of the entries associated with it to ensure the data integrity.
Of course, there are circumstances where denormalizing data can be beneficial, such as when your business rules don't require all related entries to have the exact same data, query performance is bottlenecked, or you just want simple queries at the cost of less-simple updates and inserts.
In general, you should avoid predicting future and unknown bottlenecks for the sake of up-front performance boosts. Build what you need, let the tool do the work for you - and if you have issues (or extra time) later on, then you can think about improving the design.