Front-end frameworks are mature and reasonable choices – but you this comes at a cost of crawlability, and at a cost of performance. This may or may not be relevant, depending purely on the nature of your project.
For a website, being able to directly serve HTML content matters. Sure, Google can also crawl client-side rendered websites. But other search engines don't. More importantly, client-side rendering makes your content inaccessible to crawlers from social networks or similar services. When visitors share your site on Facebook, Twitter, or Slack, their crawlers are looking for specific meta tags in order to render more than just a plain link. When users want to read your page on a read-it-later service such as Pocket or Instapaper, their crawlers need to fetch the HTML. Not supporting these use cases will limit the reach of your content.
For a web app that has no content for non-authenticated users, crawlability doesn't matter for the URLs of your app. It still matters for the publicly visible, static parts.
When you render everything client-side, you don't just have to transmit your page and wait for the Browser's rendering engine to do its thing. You need to transmit a HTML scaffold, all your JS, the data to be rendered, and any templates, then create the HTML and then actually let the browser render everything. Admittedly, if you can use HTTP/2 having to load multiple resources doesn't necessarily lead to latency issues. But the client will still have to do more processing. That can delay the perceived load time for the initial page load. If this is a web application that users are somehow invested in, this doesn't matter. They will wait. For casual users, users on mobile phones, or for websites the initial load time matters very much. Visitors might simply lose interest in your offering if it doesn't display anything useful after a few seconds. I regularly encounter fancy client-side rendered websites that simply don't display anything because they make bad assumptions.
Note that it's possible to have perceived-fast subsequent load times even without using client-side rendering. First, serve a server-side rendered page. Then do a tiny bit of progressive enhancement: when the user performs any action, don't let the browser navigate directly to that new URL. Instead, fire of a background request for the URL, display an unobtrusive progress indicator, wait until the response has finished downloading, then replace the DOM with the received HTML and update the browser history. E.g. Github does something like this. Or you can just replace parts of the page with a new HTML fragment, jQuery-style! The point is not that this is the best way to do web development, just that it's a perfectly fine, very fast, and highly compatible approach.
Note that server-side rendering does not cut you off from many of the client-side rendering benefits. A server-side frontend can still connect to an API (possibly on localhost, super fast!), can still be developed by a separate team, can still make use of NPM and so on.
The only really good reason to create a client side rendered web app is that the user interaction doesn't fit easily into a state transfer model. State transfer makes it easy to model a form-based workflow with a clear “save changes” button, or user interactions that only consist of viewing/consuming content. So client-side rendering is only a must if you have client side state that would be pointless to transfer for each user interaction, e.g. in an editor or a game.