Is JAM Stack slow compared to conventional server?

Ok, the general background first:

I think one of the most useful ways to think about this is to focus on the differences between native apps and standard web pages, and how things like ServiceWorkers and pre-rendering shift the equation a bit so that web apps can be deployed and accessed in ways that are more similar to native apps.

As well, it really comes down to how much effort you want to put into your front-end engineering.

One of the best things about JAMStack is that it gives you a lot of flexibility in where you host the static files, along with an incredibly straight forward grasp of what is going on during deployment. That said, to get the most out of this kind of set-up, you probably need to do some of the following:

1. Use ServiceWorkers to cache downloaded assets, and IndexedDB to cache data. It is true that a customer's first-load experience will have to include getting the data to begin with, and that will be at least a bit slower than just pushing the data with the initial page as you might do in a traditional web app. But with some attention to detail and using the "app shell" model of building your app, this is (usually) a non-issue.

Obviously, from that point on, you can show users cached data on load, where appropriate, and update with new data as it becomes available.

I would also point out that having pure API endpoints that just push data to the front-end often allows you to keep those APIs and their support infrastructure simpler than in other cases.

2. You might want to pre-render some or all of your pages. This is conceptually similar to server-side-rendering (SSR), but you do it at build time. It is a more limited than SSR because you don't have the browser's user-agent to generate an optimized page on the fly, but in most cases it gets the job done and is, again, conceptually and operationally simple to deploy.

With some attention to the build and deployment, a JAMStack web app is very fast to load and simple to deploy.

On to your specific case:

I'm not sure what you mean by dynamic contact, but in general dynamic, personalized content can be handled with the kind of system outlined above-- you will get the initial API call delay, but then you cache it for future use subject to cache or login-token expiration. A lot depends on what your specific flow needs to be. JAMStack won't be a match for every kind of user flow, but does work well in many cases, especially with code-splitting and other optimizations.

Generally I deploy new projects as JAMStack projects unless I have a specific reason not to. Best results will be seen, I think, with a system you set up yourself vs using a service to do it for you, but much rides on how complex your app is and how much attention you give to following guidelines such as those listed in https://web.dev/apply-instant-loading-with-prpl/

Login/logout and other dynamic logic work fine with JAMStack and whatever your auth system of choice is (JWTs, sessions, etc.)

I hope that answers your question, but please post some follow-ups if you would like more detail.

EDIT: I didn't answer you question about where to host. Any of the ones you mentioned, such as Netlify, should work well. You can also use AWS-- you can static host with S3 and CloudFront. You do the same thing with other providers/cloud services like GCP, Azure and CloudFlare workers as well.