Depends how confident you are in the "no subdomains" and "no browsers too old to understand SameSite cookie flag" conditions. Both of those have several ways to break them.
The "no subdomains" thing requires not only that you not have any subdomains, but that nobody else is able to register one for you (e.g. by gaining access to your domain registrar account), or create one for you using forged DNS responses or other DNS spoofing/poisoning. The latter case can't be directly protected against, but you can use HSTS with the includeSubDomains option to make it impractical (also, you should be doing that anyhow, to prevent SSL stripping and other HTTP attacks). In fact, given what you've told us, SSL Stripping is the thing that seems most likely to have not been considered.
Blocking browsers that don't understand SameSite isn't too hard, since all modern browsers do. Some people still use IE11, which is the most modern-ish browser that doesn't, but Microsoft is trying hard to end IE usage and you shouldn't feel bad about not supporting it. Still, you might want to use a list of known good browsers, rather than a list of known bad ones, if you want to pop up a message warning people. By the way, if you don't allow any state-changing actions via GET, then SameSite=strict is overkill and you can get a better user experience (e.g. if somebody wants to open a link into your site from another site, and have your site recognize their active session) by using SameSite=lax.
Assuming that both of the above conditions hold, you don't need additional anti-CSRF protection. However, why not add some anyhow? Anti-CSRF tokens don't have to be complicated to add; one of my favorites is requiring that the user submit a cryptographic hash (e.g. SHA2-256) or keyed hash (e.g. HMAC-SHA256) of their session token, with optional server-side key. This doesn't require any additional state for the server to store per user, is fast to compute, and is safe. However, if you already are using JS (rather than HTML forms) to submit requests to the server, there's an even easier option: just require that the client submit any non-standard header. It doesn't even have to be a secret or a user-specific value For example, if the client tries to add the custom HTTP request header CSRF: sucks to a first-party request, it'll just work. If they try doing that with a third-party request, though, the browser will first attempt a CORS pre-flight to verify whether the custom header is allowed. Since you're not responding to CORS preflights in any useful way, third-party sites can't interact with your site so long as the server requires that header on every [state-changing] request.
CSP doesn't meaningfully protect against CSRF (it protects against XSS and clickjacking), and anti-CSRF tokens don't protect against XSS (except maybe in the weird case of self-XSS), so CSP and anti-CSRF tokens are totally orthogonal.
Furthermore, CSRF doesn't exactly allow impersonating somebody - typically only XSS and session hijacking and maybe extremely badly configured CORS do that - but it does allow a "confused deputy" attack, where the victim does something they shouldn't / didn't mean to, because somebody else told them to. That's pretty similar to impersonation but not quite the same. In any case, there are lots of other attacks that aren't either of these, ranging from information-leaking attacks like cross-site search (which SameSite should mitigate) to various flavors of server-side attack like path traversal on file read/write or SQL injection or deserialization attacks. Don't focus too much on blocking just one kind, or even just one cluster, of attacks.
