With either approach 1 or approach 2 (assuming approach 1 is using embedded page and not embedded page list / page group), you will end up creating the properties in the main table and thus the reporting will be the same. Declare index comes into play for page list / page group properties where each of these properties could have 1 or more pages in it.
For a normal Page property, optimize for reporting will create the column in the main table (case / workpool table) and not as a declare index table.
What would be the best approach here design 1 or design 2 ?
This depends on where all you will use this embedded page (UI, flow actions and processing). If it is just from a reporting stand point and performance is key, I would go with design 2 since all columns are in the same table and you don't need a join.
>> Can database table have 100 exposed properties ?
That would depend on the database vendor limits. But yes, I think 100 columns is possible to have. We have seen in some scenarios, even 200 columns as well.
>> Does CaseMatch rule considers index when it searches the cases ?
I am not sure about this as case management is not really my expertise area. I would assume it doesn't OOTB.