For each extra functionality, you are going to pay for How much would depend on the function or action. It is like @TomJNowell said, even a simple echo statement costs time and memory although it is really minute and insignificant.
The real issue here is db calls as they can get very expensive depending on the size and nature of the query and this drastically increase page load times, so you would want to reduce unnecessary db calls or make use of transients and caches to store information from db calls in order to increase performance
WordPress has good cache system in place when it comes to querying the db in order to make a query more effecient. Dig around in the WP_Query class for starters and see what data is cached on a query. I’m not going to go into that now, but there are are caches that stores post meta data and taxonomy term data to help with effeciency when quering this extra post info inside a post. Just for some insight, see my answer to this question: Custom post meta field effect on the performance on the post. You should be able to run the same exact tests on this issue, and that is what I did.
When looking at the post_class() source code, you would expect it to slow the page down due to extra db calls, and that is where you are wrong. As I said, post results from a query gets cached. And that is where you answer lay. As I said, I did run a quick test or two on a set of posts (10 to be exact), and here are my results
-
With
post_class()functionality, I got 18 db calls in around an average time of 0.38 – 0.40 seconds -
Without
post_class()functionality, I got 18 db calls in around an average of 0.38 – 0.40 seconds
So the results are exactly the same. I have explained in the linked answer how you can also quickly set up a testing enviroment to test stuff like this, so be sure to try this out yourself
I would also encourage you to download and install a plugin called Query Monitor (to which I don’t have any affiliation to) on your local test intallation. This will print out a list of queries that is executed on every page load with the exact time it takes to execute each query. It also shows page load times (which I did not have a look at during my tests). This will also give you a perfect insight on how effecient your queries and page really is. I must stress this however, do not use this plugin on a live install as it prints everything directly to screen. This will look seriously wierd and scary to someone visiting your site with the plugin installed 🙂
To answer your question about whether post_class() is worth it or not, my answer would be YES. It gives you so much more control and freedom styling certain elements differently from one post to the other. You can also target specific pages or posts, terms, custom post types etc styles with css rather than using php. I personally think that omitting post_class() is like going fishing with a rod without hook, line and sinker 🙂
EDIT
Thanks to the info from @birgire in comments, the plugin Query Monitor is only loaded for admins in single installs and super admins in multisite installs. You can check out their FAQ section here