Generally speaking the managed package code base does not need to explicitly provide namespace prefixing (for Apex classes, custom objects, custom fields, field sets etc.). The Salesforce runtime understands the context of the class/object/field reference and will automatically apply the namespace prefix transparently when done within the package's code base.
LWCs have to be written using the "c-" namespace prefix "placeholder". LWCs in a managed package can be set "exposed" and thus can be dropped into Lightning Pages using the Lightning App Builder, but you cannot use a custom LWC from a package in the template of an LWC not in that package. In terms of accessing SObject data directly within LWC components using uiRecordApi's getRecord (for example) you would need to use namespaced access. You could do it like:
const field = data.fields.namespace__FieldName__c || data.fields.FieldName__c;
const value = field.value;
This allows the LWC to work with or without namespacing. However, that's not important if you plan to permanently namespace the code.
Aura is a slightly different issue; if you want to reference your components (e.g. using LightningOut and Visualforce, or when referencing another component from a component's cmp markup) you have to write reference your Aura components using the package's namespace prefix. Thus, if you wrote your code with two Aura components, "parent" and "child", and had the parent markup like:
This will fail when you package it. You must change it to use the namespace prefix (e.g. "prefix") thus:
Thus, your SOQL, VF and Apex will work as-is, but you have to namespace your Aura components and consider how SObject data access works in LWC. Any use of the (global) classes, objects or fields etc. outside the package will, however, need to include the namespace prefix in order to work.
UPDATE: With the recent (2022) introduction of Lightning Web Security as a replacement for the Locker Service, cross-namespace LWC usage becomes possible. See this overview comparison documentation for details. This means you should be able to use a component from a package in the template markup for a component outside that package. There are documented limitations.