It is difficult to find a deep element in the page.

[sachinhosmani]

The only way to find an page element in the tool is to use the inspector's search (magnifying glass), get it selected in the inspector and then switch back to the Polymer panel to find it selected there as well.

With b378375 removing scrolling of elements into view upon hovering in the tool's element tree, this issue becomes even more prominent.

[addyosmani]

How expensive would it be to introduce a version of the Inspector search field specific to the Polymer panel? (i.e something that would allow you to find elements at any depth based on a string query).

Other DevTools extensions (e.g Ember Inspector) have gone down the path of introducing their own search UI to minimize the dance between Elements pane > your extension quite effectively.

[sachinhosmani]

That's a good idea. It shouldn't be expensive to add a string query based search feature (assuming CSS selectors). The only expense is to inject scripts into the page that will do the search in the page and return us a key of the element.

Just saying, we had considered adding a search button to our tool. It was meant to work just like the inspector's:
Click the search button, click an element on the page, it gets selected in the tool's tree.

We decided against it because we should add a click event listeners on DOM elements such that the true target of the click is known when it happens. Adding a listener to the document's body won't help despite event delegation because of how shadow DOM changes the target of events coming from inside shadow DOM.
It might be inefficient, although I'm not sure if it will introduce substantial latencies.