- links are for navigation
- buttons are for action
Styling and appearance are not a factor - you can make buttons look like links, links look like buttons.Simple rule is "should this view have a url". Should the user be able to navigate directly to this page? Should it exist in the history? Should the user be able to share a URL to that page to someone else? Most times the answer to all of these is.
In your javascript application, it is trivial to do single page app view navigations (without triggering a full browser request) by listening to link clicks and acting on it just as you would if it were a button click. All frameworks and routing libraries will handle this for you out of the box. If you roll your own, its not that difficult to add this functionality.
Are tabs a view? Should they be buttons or links? What if the tabs are in the sidebar in some widget?
What about collapsible items? HN uses JavaScript to store your collapsible preferences to your account. Not shareable but consistent on page refresh. Is that good? I don't know.
The fact is, in PWA world, what's a links and what's a button is blurred, and there's nothing wrong with admitting it.
It is an action, but it navigates you to the booking page. That page should have a url and should be able to be shared. But wanting to "book now" is an action and most sites have them as a button.
General best practice IMO is any navigation link/button that is just some permalink like a profile page should be an a tag to support natural browser interactions like open in new tab or bookmark link, it also helps crawlers index your app if the interface in question is some sort of public directory you'd like indexed and has SSR. Only navigation based on ephemeral state (submitting forms etc) to things nobody would typically share a link to (logout URL, submit button going to a thankyou page) should be buttons.