The issue

This is a design oversight that has many negative consequences.
Files in behavior and resource packs do not have any kind of consistent namespace support, or implementations. As a result, packs conflict with each other and vanilla, and are disorganized.
Here is a list of file types found in behavior/resource packs, and their level of namespace support:

Type	Supports namespaces?
Entities	Yes, with identifier
Items	Yes, with identifier
Loot tables	No. Loot tables are referred to exclusively by their path, relative to the pack root, including the file extension. They don't even have to be placed in the loot_tables folder or have the json extension, unlike every other resource file.
Recipes	Yes, with identifier
Spawn rules	Yes, with identifier
Dialogues	No. These use plain strings called "tags" for some reason as identifiers.
Trade tables	No. These behave identically to loot tables.
Functions	No. Functions are referred to by their path. Unlike loot tables however, they are properly referenced relative to the functions folder, require the proper file extension to be read, and create identifiers without said extension.
Biomes	No. These use identifier but a namespace is absent. The documentation says it's optional, which defeats the entire point of namespaces, especially considering vanilla doesn't even use one. Identifiers are not strings with a colon to the left sometimes, the namespace is a fundamental part of a resource location.
Blocks	Yes, with identifier
Features	No. These behave identically to biomes.
Feature rules	No. These behave identically to biomes.
Structures	Yes. The namespace is derived from the name of the folder inside of the structures folder. This is the closest to the ideal solution. However, the folder structure creates the issue Java data packs had prior to 1.13, namely redundant namespace folders. Resources should go inside the namespace folder, not the other way around.
Attachables	Yes, with identifier
Fogs	Yes, with identiifer
Animation controllers	No. Instead, identifiers are of the form controller.animation.name. Vanilla's make no attempt to include a namespace.
Animations	No. Instead, identifiers are of the form animation.name. Vanilla's make no attempt to include a namespace.
Models	No. Instead, identifiers are of the form geometry.name. Vanilla's make no attempt to include a namespace.
Particles	Yes, with identifier
Render controllers	No. Instead, identifiers are of the form controller.render.name. Vanilla's make no attempt to include a namespace.
Sounds	No. Sounds are referred to by their path. Like loot tables, the path starts in the root folder instead of the proper folder. This means you can put sound files in whatever random folder you want, unlike every other resource.
Sound events	No. The identifier is a string with no namespace.
Translation keys	Inconsistent. It is intended for translation keys themselves to not be namespaced identifiers, but keys such as tile.dirt.name should instead be block.minecraft.dirt.
Textures	No. These behave identically to sounds.

As you can see, bedrock's support of proper resource locations is a complete mess. Practically every type of file has its own completely random ad-hoc implementation for how it should be identified.

In Java Edition, every file is referenced using its namespaced "resource location," which is derived entirely and unambiguously from its path. So a function located in data/project/functions/attack.mcfunction has the resource location project:attack. It's that simple, and is the case for everything, from images and sounds to functions and loot tables. This greatly simplifies the organization of files, and the cognitive burden of figuring out how to reference them. You don't get to decide whether you want to use a namespace or not because all of your files must go in your namespace's folder! This is the case for vanilla as well as custom packs.

Vanilla bedrock itself ignoring namespaces on many of its assets is a major issue! Identifiers without namespaces in vanilla force packmakers to choose between either (A) following vanilla's example by excluding namespaces, causing conflicts with either vanilla itself in the future, or packs that make the same choice; or (B) adding hacky faux-namespaces to as many assets as possible, creating duplicate folders and disorganized projects.