You could implement some test data and do a test to see which returns better results.
I did this for analytics when I wasn’t sure if doing a list of analytics on a particular listing was better than having a separate database data type for analytics and just put the ID as a text field of the listing…as a side note, the description from this linked post indicates that when you use a data type of thing B as a related field on thing A and you search for thing A you are loading only the ID of the related thing B in text form, and not all of the related data, so my use of adding a text field on thing A that is the ID of thing B makes no material difference to the search results performance, but it does hinder my ability to make quick references to the related thing B.
What I found was a list of things took longer to return the results than having a separate database data type and do the search on that data type because of the large number of items that would have been on the list.
I believe what you linked to, written by one of the founders, could be considered as the expert advice best to adhere to.
So, if your list will go beyond 100 items, you are probably on the right track with your setup…there has been some recent activity on the forum regarding the use of multiple relationships, so that you have thing A as a related field on thing B and have thing B as a related field on thing A…one user reported this as their preferred method for optimal performance and mentioned a course they were planning to release with demonstrations but I have not seen the course released yet.
There was also a book released
that may be worth purchasing to read through to conjure up some other ideas of how to optimize