It appears readmatrix is limited to returning one type of data in the output array as the 'OutputType' named parameter is limited to a scalar string/cell string. Therefore, there's no way to tell it to return the various types of data that may be in different columns in a spreadsheet(*).
readtable on the other hand, can and does support variables of different type by column and so can handle a spreadsheet similar to your description and is certainly the best option for that type of a spreadsheet when you want all the data and not just a subset of a given data type. A table, however, is limited to have the same number of rows in every variable so if the spreadsheet isn't perfectly regular, it will fill in a bunch of missing values down to the furtherest extent in the spreadsheet unless you limit the range. Sometimes this is ok, other times it's a pain.
xlsread is slow but has the facility to return all of what is in the spreadsheet; it does so by returning numeric and text fields separately, however, whereas a table contains them in one data structure retaining their type (with some help, sometimes from an import object with, particularly, dates). If you want the full spreadsheet unadulterated, the last optional raw output array is a cell array of the whole spreadsheet from which one can retrieve any piece of information from any row/col cell regardless of its type or whether it is consistent with the type of those cells around it. Sometimes, this feature is also invaluable. xlsread is the one option that existed before the introduction of any of the more general data classes except for cell arrays which is why it returns separate variables; there was no other option at the time.
The doc implies readmatrix will return a table if one passes the optional opts structure but I see little reason then for it in lieu of readtable which also can use an opts object.
Seems to me TMW is continuing to just add stuff just to be adding it without any clearly defined (to the user base, anyway) direction of where they're headed and why they don't just improve existing functions instead of overloading namespace and bloating code size with multiple essentially duplicated functionalities.
(*) And, of course, for an array other than a cell array, there can only be one data class for the array, anyway. Without the importoptions optional input, readmatrix just punts and returns only what numeric data it can find without offering the option of returning the text data or the combined that does xlsread. This, somehow, seems a step backwards and why not just rewrite xlsread if want to improve it? Instead, for historical reasons, it can never be actually removed and we've just got yet another eventually more or less orphaned function hanging around like textread (which, incidentally, still has some features that make it more useful on occasion than the favored textscan).