Storybook uses Testing Library DOM because it's executable in every browser, not just Playwright's special browser. You can read about why TL doesn't support CSS queries here.

https://testing-library.com/docs/dom-testing-library/intro/

We are considering adding the locator API though. Request noted!

Some teams have actually managed to swap out Playwright for Play Functions when doing end-to-end testing, and it’s worked out pretty well for them. That said, one of the bigger headaches is the lack of built-in support for CSS selectors. To get around that, devs usually fall back on XPath or other tricks-like targeting elements by data attributes or text content. This isn’t really a technical limitation, though-it’s more about how Play Functions was designed. The idea is to keep things semantic and framework-agnostic, which can feel a bit limiting at first, but it pushes you toward writing tests that are cleaner and easier to maintain in the long run. Still, fingers crossed that future updates make life a little easier.

You can query elements using css selectors in Storybook by using querySelector/querySelectorAll like so:

play: async ({ canvasElement }) => {
	const body = canvasElement.ownerDocument.body;
	const input = body.querySelector('input[data-attribute="test"]')
	await userEvent.click(input);
}

Although, as people mentioned above, relying on CSS selectors is fragile. Testing library has a great read on Query Priorities explaining it in more details.
tldr: write tests the same way users would interact with the UI, e.g. aria-role=name is better than .name-input-classname-SIQIj4