Attributes just define a “schema” of sorts which informs WordPress which persistent data is associated with a block, and how WordPress should parse it from the block’s saved markup/block grammar. WordPress makes no assumptions about if or how a UI should be constructed to expose attributes to the end-user – you must construct the UI yourself.
The exception to this may be Block Supports, which can be used to register certain core capabilities for a block that may come with some limited automatic UI – adding "colors" entries will provide a color picker for each entry and store the selections in a style attribute, for instance.
For constructing the UI in other cases, the standalone React components provided by the @wordpress/components package are more than sufficient for most use-cases (but if not, there is nothing stopping you from using React components from third-party sources!). Previews, docs, and examples for the components can be found over on the Gutenberg Storybook instance. Docs can also be found in the Components Reference Guide. A couple other components which are more dependent on WordPress and as such are not suitable for inclusion in the library of standalone components reside in their own packages, such as @wordpress/rich-text.
Any components returned by your edit function will be displayed within the block. Rendering components in the sidebar is accomplished by wrapping the components in @wordpress/block-editor‘s <InspectorControls> component.
Some good general instruction and advice can be found in the Block Editor Handbook‘s Create a Block Tutorial.