Do I still need CSRF protection when SameSite is set to Lax?

You still need "traditional" CSRF-protection. Maybe this will change in the years to come, but as of writing the SameSite attribute should be viewed more as defense in depth than your one and only line of defence. This is for a few reasons:

• According to caniuse.com, there is currently only browser support for 85% or 92% (if you count partial support) of global users. For instance IE 11 on Windows 8 (still used in many offices around the world) doesn't support it, and neither does the UC Browser on Android.
• Relying on browsers to auto upgrade to Lax is even worse, since not all supporting browsers do this. I don't have any numbers, though. But at the very least, you need to explicitly set the flag.
• Do you really trust all current and future developers of your application to never change server state on a GET request? I wouldn't do so - I would not even trust myself. If you want to rely on SameSite, set it to Strict.
• If you do not trust your subdomains, SameSite will not help you. See this great article by jub0bs.
• As I write in this answer (second bullet point) there are some cases where you will always need a traditional CSRF-defence.

TL;DR: Just the SameSite flag is not enough to protect your users from CSRF.

SameSite=Lax means NO CSRF protection for GET requests.

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Cookies are allowed to be sent with top-level navigations and will be sent along with GET request initiated by third party website. This is the default value in modern browsers.

In an ideal case, that may be sufficient CSRF protection. But the real world is far from ideal. Web APIs with non-safe GET requests are far from rare (a GET request that changes a server-state, although it shouldn't, according to the HTTP specifications).

Also, not all browsers correctly implement the samesite flag (yet): https://caniuse.com/#feat=same-site-cookie-attribute

And some older never will.

It's safer to implement additional explicit CSRF protection like synchronizer token pattern.

With samesite being supported in all major browsers, it's a borderline issue.

• As a developer, I typically use either a framework with built-in CSRF protection (e.g. Spring Security) or Ajax endpoints. Implementing CSRF protection is no hassle, and I continue to use it now we have samesite cookies.

• As a pen tester, I'd raise lack of CSRF protection on POST requests as low-risk or informational. If a GET request allowed an action, I'd flag at a higher risk level, depending on what actions were vulnerable.